7.07. Информационная безопасность

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО

Разработчику Инженеру

Информационная безопасность

Информационная безопасность (Information Security, InfoSec) держится на «трёх китах»:

C – Confidentiality (Конфиденциальность)
I – Integrity (Целостность)
A – Availability (Доступность)

Это основа информационной безопасности, и на её основе строятся все политики, технологии и практики в этой области.

Все они взаимосвязаны. Если слишком усиливать конфиденциальность, нарушится доступность (слишком много проверок). Если игнорировать целостность, можно подставить конфиденциальность (подмена данных), а если нет доступности, то даже самые защищённые данные будут бесполезными.

Сеть должна использовать шифрование, проверять целостность пакетов, использовать балансировщики. Приложение должно шифровать и валидировать данные, выполнять мониторинг. База данных должна ограничивать права, контролировать изменения и использовать резервные копии. Пользовательский интерфейс должен не показывать лишнего, санитизировать ввод и использовать быстрые загрузки. Всё это - совокупность CIA.

Конфиденциальность

Конфиденциальность отвечает на вопрос «Кто может видеть данные?».

Метод	Описание
Шифрование данных (в покое и в движении)	Защита информации путём преобразования в нечитаемую форму. Даже при компрометации данных злоумышленник не сможет их расшифровать без соответствующего ключа.
Многофакторная аутентификация (MFA)	Процесс проверки личности пользователя на основе комбинации нескольких факторов: знания (пароль), владения (устройство, токен) и биометрии (отпечаток, лицо).
Управление доступом (RBAC, ABAC)	Механизмы разграничения прав доступа: ролевое (RBAC — на основе должности) или атрибутное (ABAC — на основе набора характеристик пользователя, ресурса и контекста).
Политики паролей	Требования к сложности паролей, регулярной смене и безопасному хранению (например, с использованием хеширования с солью).
DLP (Data Loss Prevention)	Системы и политики, направленные на предотвращение несанкционированной передачи или утечки конфиденциальных данных внутри и за пределами организации.
Обучение сотрудников	Повышение осведомлённости персонала о методах социальной инженерии, фишинга и правилах работы с конфиденциальной информацией.

Нарушением конфиденциальности является утечка данных, перехват токенов авторизации, неправильное раскрытие информации в сети.

Цель конфиденциальности - убедиться, что информация доступна только тем, кто имеет на это право.

Целостность

Целостность данных должна обеспечиваться на протяжении всего их жизненного цикла. Она отвечает на вопрос «Кто может изменять данные?» и «Как мы знаем, что они не были изменены?»

Метод	Описание
Хэши и цифровые подписи	Позволяют проверить целостность данных: любое изменение информации приводит к несоответствию хэша или недействительности подписи.
Контроль версий	Системы отслеживания изменений (например, Git) фиксируют все модификации кода и документов, обеспечивая возможность восстановления предыдущих состояний.
Разрешения на запись	Ограничение прав на редактирование данных только уполномоченным пользователям или системам.
Логирование и аудит	Фиксация всех операций с данными для последующего анализа, выявления инцидентов и установления ответственности.
Интеграционные проверки	Валидация данных при вводе или обновлении для обеспечения их корректности и соответствия заданным правилам.
Блокчейн (в некоторых системах)	Используется как неизменяемый журнал транзакций, где каждая запись связана с предыдущей, что делает подделку исторических данных вычислительно неосуществимой.

Нарушением целостности является подмена данных в базе без разрешения, изменение файла без уведомления владельца, и модификация трафика.

Цель целостности - обеспечить неизменность и достоверность информации на всех этапах её жизни.

Доступность

Доступность определяет, что данные должны быть доступны тем, кому они нужны, когда они нужны.

Метод	Описание
Резервное копирование и восстановление	Регулярное создание копий данных с возможностью их восстановления в случае потери из-за сбоя, ошибки или атаки.
Высокая доступность (HA)	Архитектурное решение с использованием резервных серверов и автоматическим переключением при отказе основного компонента.
Балансировка нагрузки	Распределение входящих запросов между несколькими серверами для повышения производительности и отказоустойчивости.
DDoS-защита	Средства фильтрации сетевого трафика, предотвращающие перегрузку сервисов за счёт массовых внешних запросов.
Мониторинг и оповещение	Непрерывный сбор метрик состояния систем и автоматическая отправка уведомлений при отклонениях от нормы.
SLA (Service Level Agreement)	Договорные обязательства по уровню доступности и времени реакции на инциденты, измеряемые в процентах (например, 99.9%).
Регулярное техническое обслуживание	Плановые работы: обновление ПО, установка патчей, очистка логов, дефрагментация и другие операции для поддержания стабильности системы.

Нарушение доступности - это DDoS-атака, сбой оборудования, отказ диска/сервера, чрезмерная нагрузка на БД.

Цель - гарантировать, что авторизованные пользователи могут получить доступ к данным и ресурсам в нужный момент.

Опасности и безопасность

Опасности строятся на базе рисков, угроз и уязвимостей.

Риск - это вероятность возникновения угрозы, которая может привести к ущербу при наличии уязвимости. К примеру, риск утечки данных через слабые пароли.

Угроза - это потенциальный источник вреда или инцидента, способного нанести ущерб системе. Пример - хакерская атака, фишинг, внутренний злоумышленник.

Уязвимость - это слабое место в системе, которое можно использовать для совершения атаки. Пример - незапатченная библиотека, слабый пароль, открытое API.

Основная формула:

Риск = Угроза x Уязвимость.

Если нет ни одной из составляющих — риска нет.

Инциденты - это любые события, которые угрожают конфиденциальности, целостности или доступности информации.

В случае возникновения инцидентов, необходимо своевременно на него отреагировать в соответствии с планом.

План реагирования на инциденты (IRP - Incident Response Plan) включает в себя следующие этапы:

Подготовка: обучение команды, инструменты, документация;
Обнаружение: логи, SIEM, мониторинг;
Ограничение ущерба: изоляция, отзыв токенов, блокировка IP;
Расследование: кто, что, где, когда;
Восстановление: восстановление из бэкапа, патчи;
Уроки: анализ, улучшение, обновление процедур.

В случае возникновения проблем - утечки данных, изменении условий, взломе учётной записи, нужно уведомить пользователей в течение 72 часов, объяснить, что произошло и указать, какие данные могли быть скомпрометированы.

CERT (Computer Emergency Response Team) — организация, которая помогает в расследовании и реагировании на кибератаки. В РФ это RU-CERT, который осуществляет сбор, хранение и обработку статистических данных, связанных с распространением вредоносных программ и сетевых атак на территории РФ.

Эксплойт - конкретный код или метод, используемый для эксплуатации уязвимости. Пример - SQL-инъекция, XSS-эксплойт, RCE (Remote Code Execution).

Несанкционированный доступ подразумевает получение доступа к данным или системе без разрешения. От этого защититься можно при помощи ролевой модели, двухфакторной аутентификации и аудита активности. К примеру, это может быть взлом аккаунта через подбор пароля, использование чужого токена авторизации, получение прав администратора через IDOR, перехват сессии.

Безопасность приложений как раз рассчитана на защиту от несанкционированного доступа и эксплойтов.

OWASP (Open Web Application Security Project) — это некоммерческая организация, которая выпускает список TOP 10 самых опасных уязвимостей веб-приложений.

OWASP Top 10 — это международно признанный стандарт и рейтинг наиболее критичных уязвимостей веб-приложений. Документ обновляется каждые 3–4 года и служит основой для повышения осведомлённости разработчиков и специалистов по безопасности, а также для внедрения лучших практик защиты.

Сейчас, среди таких проблем перечисляются:

Нарушение контроля доступа (Broken Access Control) связаны с неправильным контролем;
Сбои криптографии (Cryptographic Failures) связаны со слабым шифрованием или его отсутствием;
Инъекции (Injection) предполагают внедрение вредоносного кода (SQLi, CMDi, XSS);
Небезопасный дизайн (Insecure Design) - уязвимости на уровне архитектуры;
Ошибки конфигурации безопасности (Security Misconfiguration) - неправильная настройка серверов или сервисов;
Уязвимые и устаревшие компоненты (Vulnerable and Outdated Components) говорят об использовании устаревших библиотек;
Ошибки идентификации и аутентификации (Identification and Authentication Failures) - это очевидные проблемы с логином и паролем;
Нарушения целостности ПО и данных (Software and Data Integrity Failures) - это уязвимости при обновлении и версионировании;
Ошибки логирования и мониторинга безопасности (Security Logging and Monitoring Failures) говорят об отсутствии логирования или оповещений или их неправильной настройке;
Подделка запросов на стороне сервера (Server-Side Request Forgery) предполагает принуждение сервера к запросам от своего имени.

Методы защиты информации

В эпоху цифровой трансформации информация становится не просто активом — она превращается в основу функционирования государств, бизнеса и частной жизни. Утрата, искажение или несанкционированный доступ к данным могут повлечь за собой не только финансовые убытки, но и репутационный ущерб, юридическую ответственность и даже угрозу национальной безопасности.

Примеры катастрофических последствий отсутствия адекватной защиты информации хорошо известны:
— Утечка клиентской базы приводит к массовому мошенничеству, судебным искам и утрате доверия;
— Шифрование серверов вымогателями парализует бизнес на недели и месяцы, особенно если отсутствуют корректные резервные копии;
— DDoS-атаки делают веб-сервисы недоступными, подрывая доверие пользователей и вызывая прямые финансовые потери;
— Компрометация API открывает путь к неограниченному доступу к внутренним системам, поскольку API часто используются как точка интеграции между сервисами и доверяются по умолчанию.

Именно поэтому современная информационная безопасность (ИБ) строится не на отдельных «заплатках», а на системном подходе, в котором взаимосвязаны процессы разработки, инфраструктуры, управления данными и человеческого фактора. Ниже представлено всестороннее описание методов защиты информации, классифицированных по принципам, уровням реализации и функциональным направлениям.

Системный подход к защите информации

Безопасность — это не набор инструментов, а непрерывный процесс, пронизывающий весь жизненный цикл информационных систем. Эффективная защита требует:

Безопасной разработки кода: программисты должны осознавать типичные уязвимости (SQL-инъекции, межсайтовый скриптинг, удалённое выполнение кода) и применять защищённые паттерны (параметризованные запросы, экранирование вывода, валидацию входных данных).
Настройки безопасной инфраструктуры: корректная конфигурация сетей, серверов, баз данных, управление правами доступа, ведение централизованных логов и их мониторинг.
Проектирования архитектуры с учётом безопасности: применение принципов Zero Trust («не доверяй никому, проверяй всё»), сегментация сетей для ограничения латерального движения атакующих, шифрование каналов передачи и хранилищ данных.
Защиты самих данных: независимо от того, где они находятся — в продакшене, тестовой среде или аналитической системе, данные должны быть либо анонимизированы, либо защищены маскировкой, либо зашифрованы.
Регулярной верификации уязвимостей: проведение пентестов, автоматизированных сканирований (SAST/DAST/SCA), анализ инцидентов и постмортемов.
Управления политиками безопасности: от сертификатов и ключей до процедур восстановления после сбоев и регламентов реагирования на инциденты.
Осознания рисков и соответствия требованиям: информационная безопасность должна быть вписана в бюджет, а её уровень — обоснован рисками и требованиями регуляторов (GDPR, ISO/IEC 27001, ФЗ-152 и др.).

Классификация методов защиты информации

Для систематического понимания методов защиты целесообразно разделить их по двум основным критериям: уровню реализации и функциональному назначению.

По уровню реализации

Правовые методы
Определяют юридическую ответственность за нарушение конфиденциальности, целостности и доступности информации. Примеры:
— GDPR (Общий регламент по защите данных) в Европейском союзе;
— Федеральный закон №152-ФЗ «О персональных данных» в Российской Федерации;
— HIPAA (Health Insurance Portability and Accountability Act) в США, регулирующий медицинские данные.
Организационные методы
Включают внутренние регламенты, инструкции, политики безопасности, обучение персонала и управление инцидентами. Эффективность этих методов напрямую зависит от культуры безопасности внутри организации. Например, политика паролей, процедуры onboarding/offboarding, регулярные учения по реагированию на фишинг.
Технические (аппаратно-программные) методы
Сюда относятся все технологические средства защиты:
— Криптографические алгоритмы;
— Сетевые экраны и системы обнаружения вторжений;
— Антивирусные решения и EDR-платформы;
— Инструменты управления доступом и шифрования данных.

По функциональному назначению

Превентивные (предупреждающие)
Направлены на предотвращение инцидентов: применение патчей, жёсткая конфигурация систем, многофакторная аутентификация, обучение сотрудников.
Детективные (обнаруживающие)
Позволяют выявить факт компрометации: ведение логов, SIEM-системы, сетевые и хостовые системы обнаружения вторжений (IDS/IPS), аномалии в поведении пользователей.
Корректирующие (восстанавливающие)
Обеспечивают восстановление после инцидента: резервное копирование, планы аварийного восстановления, восстановление систем из известных «чистых» состояний.

Криптографические методы

Криптография — основа современной защиты данных. Она применяется как для обеспечения конфиденциальности, так и для подтверждения целостности и подлинности.

Симметричное шифрование
Использует один и тот же ключ для шифрования и расшифровки. Примеры: AES (Advanced Encryption Standard), ChaCha20. Отличается высокой производительностью, но требует безопасного канала для передачи ключа.
Асимметричное шифрование
Применяет пару ключей: публичный (для шифрования) и приватный (для расшифровки). Примеры: RSA, ECC (Elliptic Curve Cryptography). Лежит в основе TLS/SSL, электронной подписи и безопасного обмена ключами.
Хеширование и электронная подпись
Криптографические хеш-функции (SHA-256, BLAKE3, ГОСТ Р 34.11-2012) обеспечивают целостность данных. Электронная подпись (на основе ГОСТ Р 34.10-2012 или ECDSA) подтверждает авторство и неотказуемость.
Протоколы обмена ключами
Такие как Diffie-Hellman или его эллиптические варианты (ECDH), позволяют двум сторонам сгенерировать общий секрет по открытому каналу без предварительного обмена информацией.

Защита на уровне систем и сетей

Информационные системы функционируют в среде, где угрозы исходят как извне, так и изнутри. Поэтому защита должна быть многоуровневой — от периметра до хоста.

Брандмауэры (Firewall)
Фильтруют сетевой трафик на основе правил: по IP-адресам, портам, протоколам. Современные Next-Generation Firewalls (NGFW) способны анализировать трафик на уровне приложений, блокировать известные вредоносные домены и интегрироваться с системами угроз (Threat Intelligence).
Системы обнаружения и предотвращения вторжений (IDS/IPS)
IDS (Intrusion Detection System) пассивно отслеживает аномалии и сигнатуры атак (например, Snort, Suricata). IPS (Intrusion Prevention System) активно блокирует подозрительный трафик в реальном времени. IDS/IPS могут работать как на сетевом, так и на хостовом уровне (HIDS/HIPS).
VPN (Virtual Private Network)
Обеспечивает зашифрованный туннель между устройствами или сетями. Используемые протоколы: IPSec (стандарт для корпоративных сетей), OpenVPN (гибкий и открытый), WireGuard (современный, быстрый и минималистичный). Важно помнить: VPN не заменяет аутентификацию и авторизацию — это лишь канал, а не система доступа.
WAF (Web Application Firewall)
Специализированный фильтр для HTTP/HTTPS-трафика, защищающий веб-приложения от OWASP Top 10 уязвимостей: SQL-инъекций, XSS, RCE, path traversal. Может быть реализован как на уровне приложения (ModSecurity), так и как облачный сервис (Cloudflare, AWS WAF).
DDoS-защита
Атаки типа «отказ в обслуживании» перегружают ресурсы сервера или канала связи. Защита включает:
— Rate limiting (ограничение запросов с IP);
— Анти-DDoS-сервисы (Cloudflare, AWS Shield, Yandex DDoS Protection);
— Архитектурную устойчивость (масштабируемость, географическое распределение).

Безопасность операционных систем и хостов

Даже самая защищённая сеть бесполезна, если хосты скомпрометированы.

Принцип минимальных привилегий
Пользователи и процессы должны иметь только те права, которые необходимы для выполнения их задач. Это ограничивает потенциальный ущерб при компрометации учётной записи или сервиса.
Мандатный контроль доступа (MAC)
В отличие от дискреционного (DAC), где владелец объекта управляет доступом, MAC задаётся централизованной политикой. Примеры: SELinux (в RHEL/CentOS), AppArmor (в Ubuntu/SUSE). Эти системы предотвращают несанкционированное поведение даже от привилегированных процессов.
EDR и антивирусные решения
Современные Endpoint Detection and Response (EDR) системы (например, CrowdStrike, Microsoft Defender for Endpoint) не просто сканируют файлы на вирусы, а ведут постоянный мониторинг поведения процессов, выявляя аномалии и позволяя проводить расследования на уровне хоста.
Патч-менеджмент
Регулярное обновление ОС, библиотек и приложений — один из самых эффективных способов предотвращения эксплуатации известных уязвимостей. Автоматизация этого процесса критически важна в крупных инфраструктурах.

Облачная безопасность

Миграция в облако не отменяет ответственность за безопасность — она лишь перераспределяется.

Модель совместной ответственности (Shared Responsibility Model)
Провайдер (AWS, Azure, GCP) отвечает за безопасность облака (физическая инфраструктура, гипервизоры), клиент — за безопасность в облаке (данные, ОС, приложения, настройки сетей и IAM).
Шифрование в облаке
— At rest — данные на дисках (шифруются KMS-ключами);
— In transit — при передаче по сети (TLS 1.2+);
— In use — при обработке (конфиденциальные вычисления, например, Intel SGX или AWS Nitro Enclaves).
IAM (Identity and Access Management)
Централизованное управление идентификацией и доступом. Используются политики на основе ролей (RBAC), атрибутов (ABAC), временное делегирование прав (STS), а также принцип «нулевого доверия»: каждая операция проверяется, даже внутри доверенной зоны.
CSPM (Cloud Security Posture Management)
Инструменты (Wiz, Palo Alto Prisma Cloud, AWS Config) автоматически проверяют конфигурации на соответствие best practices и стандартам (CIS Benchmarks), выявляя открытые бакеты S3, неиспользуемые права IAM, незашифрованные тома и т.п.

Защита приложений и данных

Современные приложения — основная цель атак, так как через них осуществляется доступ к данным.

DevSecOps
Интеграция безопасности на всех этапах жизненного цикла разработки: от проектирования до эксплуатации. Безопасность — не финальный этап, а непрерывный процесс.
SAST (Static Application Security Testing)
Анализ исходного кода на наличие уязвимостей без запуска приложения. Инструменты: SonarQube, Checkmarx, Semgrep.
DAST (Dynamic Application Security Testing)
Тестирование работающего приложения «снаружи», как это сделал бы злоумышленник. Инструменты: OWASP ZAP, Burp Suite, Acunetix.
SCA (Software Composition Analysis)
Проверка сторонних зависимостей (библиотек, пакетов) на наличие известных уязвимостей (CVE). Инструменты: Snyk, Dependabot, OWASP Dependency-Check.
OWASP Top 10
Стандартный справочник наиболее критичных уязвимостей веб-приложений, обновляемый раз в несколько лет. Включает:
— Инъекции (SQLi, OS command);
— Нарушения аутентификации;
— Утечки конфиденциальных данных;
— XML External Entities (XXE);
— Неправильная конфигурация безопасности;
— Межсайтовый скриптинг (XSS);
— Небезопасная десериализация;
— Использование компонентов с известными уязвимостями;
— Недостаточная логика бизнес-процессов.

Защита данных

Данные — конечная цель большинства атак. Поэтому защита должна быть сконцентрирована не столько на системах, сколько на самих данных.

DLP (Data Loss Prevention)
Системы предотвращения утечек анализируют потоки данных и блокируют или шифруют передачу конфиденциальной информации. Например, DLP может предотвратить отправку базы клиентов по email, выгрузку в облако или копирование на USB-накопитель. Работает на основе классификации данных и политик контентного анализа.
Маскирование и анонимизация
В тестовых, аналитических и демонстрационных средах реальные данные заменяются на синтетические или искажённые. Маскирование сохраняет формат (например, ***-**-1234 вместо СНИЛС), а анонимизация делает невозможным идентификацию субъекта даже при наличии дополнительной информации (в соответствии с GDPR).
Токенизация
Чувствительные данные (номера карт, PAN) заменяются на токены — случайные идентификаторы, не имеющие математической связи с оригиналом. Используется в платёжных системах (PCI DSS требует минимизации хранения PAN). В отличие от шифрования, токены не поддаются обратному преобразованию без доступа к специальному сервису (Vault).
Шифрование на уровне приложения
Даже администратор базы данных не должен видеть конфиденциальные поля в открытом виде. Такой подход — Application-Layer Encryption — обеспечивает защиту «от инсайдера» и при компрометации БД. Ключи управления выносятся в отдельные системы (HSM, KMS).

Управление доступом и идентификацией

Корректное управление доступом — краеугольный камень безопасности.

Аутентификация
Подтверждение личности пользователя. Эволюция методов:
— Пароли (с требованиями сложности и ротацией);
— Двухфакторная (2FA) и многофакторная аутентификация (MFA) — что-то, что у вас есть (токен), и что-то, что вы знаете (PIN);
— Биометрия (отпечатки, лицо) — удобна, но необратима при утечке;
— FIDO2/WebAuthn — стандарт без паролей, использующий криптографические ключи на устройстве (YubiKey, Touch ID).
Авторизация
Определение, какие действия разрешены после аутентификации. Подходы:
— RBAC (Role-Based Access Control) — права привязаны к ролям («админ», «аналитик»);
— ABAC (Attribute-Based) — доступ зависит от атрибутов субъекта, объекта и контекста (время, геолокация);
— PBAC (Policy-Based) — гибкие политики, описанные на языках типа Rego (Open Policy Agent).
SSO (Single Sign-On)
Единая точка входа упрощает управление и повышает безопасность. Протоколы:
— SAML — для корпоративных приложений;
— OAuth 2.0 — делегирование доступа (например, «Войти через Google»);
— OpenID Connect — надстройка над OAuth 2.0 для аутентификации.
Zero Trust Architecture (ZTA)
Архитектурная модель, отвергающая концепцию «доверенной сети». Каждый запрос проверяется независимо от источника. Принципы:
— Никогда не доверять, всегда проверять;
— Минимизация поверхности атаки;
— Динамическая авторизация на основе риска;
— Микросегментация и строгий контроль устройств.

Резервное копирование и восстановление

Даже при идеальной защите возможны сбои — технические, человеческие или катастрофические.

Правило 3-2-1
— 3 копии данных (оригинал + 2 резервных);
— на 2 разных типах носителей (диск + лента или диск + облако);
— 1 копия хранится вне офиса (офсайт или в облаке).
RPO и RTO
— RPO (Recovery Point Objective) — максимальный допустимый интервал между последней резервной копией и моментом сбоя (например, 15 минут);
— RTO (Recovery Time Objective) — максимально допустимое время восстановления (например, 2 часа).
Immutable backups
Резервные копии, защищённые от изменения или удаления в течение заданного срока. Критически важны для защиты от вымогателей, которые стремятся уничтожить бэкапы перед шифрованием.
Disaster Recovery Plan (DRP)
Документированный и регулярно тестируемый план восстановления ИТ-инфраструктуры после крупного инцидента (пожар, наводнение, массированная атака). Включает: резервные площадки, процедуры запуска, команды реагирования, коммуникационные каналы.

Мониторинг, логирование и реагирование

Обнаружение инцидента — ключ к минимизации ущерба. Без систематического мониторинга атака может оставаться незамеченной месяцами.

SIEM (Security Information and Event Management)
Централизованная платформа для сбора, нормализации, корреляции и анализа логов с серверов, сетевых устройств, приложений и облачных сервисов. Позволяет выявлять сложные атаки, состоящие из множества этапов. Примеры: Splunk, Elastic Stack (ELK), Graylog, IBM QRadar, Microsoft Sentinel.
SOC (Security Operations Center)
Команда специалистов, осуществляющая круглосуточный мониторинг, расследование и реагирование на инциденты. В крупных организациях SOC работает в три смены, используя автоматизированные playbooks и интеграции с ITSM-системами.
Incident Response (IR)
Структурированный подход к обработке инцидентов безопасности. Стандарт NIST SP 800-61 определяет фазы:
— Подготовка (политики, инструменты, обучение);
— Обнаружение и анализ;
— Сдерживание, искоренение и восстановление;
— Последующие действия (постмортем, улучшение защиты).
Threat Hunting
Проактивный поиск угроз, которые не были обнаружены автоматизированными системами. Основан на гипотезах, интеллектуальном анализе аномалий и знании тактик атакующих (MITRE ATT&CK). Threat Hunting требует высокой квалификации и глубокого понимания инфраструктуры.

Стандарты и соответствие требованиям (Compliance)

Соответствие нормативным требованиям — не только юридическая необходимость, но и доказательство зрелости системы информационной безопасности.

ISO/IEC 27001
Международный стандарт, описывающий требования к системе менеджмента информационной безопасности (ISMS). Основан на цикле PDCA (Plan-Do-Check-Act) и требует регулярного аудита, оценки рисков и непрерывного улучшения.
GDPR (General Data Protection Regulation)
Регулирует обработку персональных данных граждан ЕС. Вводит такие понятия, как «защита по умолчанию» (privacy by design), права субъектов данных (на доступ, исправление, удаление) и обязательное уведомление об утечках в течение 72 часов.
PCI DSS (Payment Card Industry Data Security Standard)
Обязателен для всех организаций, обрабатывающих платёжные карты. Требует сегментации сети, шифрования PAN, регулярных сканирований уязвимостей и аудитов.
NIST Cybersecurity Framework (CSF)
Гибкий, необязательный, но широко применяемый фреймворк в США и мире. Основан на пяти функциях: Identify, Protect, Detect, Respond, Recover.
Федеральный закон №152-ФЗ (Россия)
Регулирует обработку персональных данных на территории РФ. Требует уведомления Роскомнадзора, согласия субъекта, хранения данных россиян на серверах в РФ (с 2023 года — с ужесточёнными требованиями к уровням защищённости).
ГОСТы в области криптографии
В России применяются отечественные алгоритмы:
— ГОСТ Р 34.10-2012 — электронная цифровая подпись на эллиптических кривых;
— ГОСТ Р 34.11-2012 (Стрибог) — криптографическая хеш-функция;
— ГОСТ Р 34.12-2015 (Кузнечик, Магма) — блочные шифры.
Использование ГОСТов часто требуется в госсекторе и критической инфраструктуре.

Сертификаты, MITM

Начнём с интересного - с сертификации. Ранее мы изучили то, что еcть HTTP, а есть HTTPS, и возможно, не совсем поняли разницу между ними, кроме того, что магическая S предполагает защиту.

Сейчас безопасность передачи данных в интернете играет ключевую роль, а HTTPS является стандартом для обеспечения конфиденциальности, целостности и аутентификации при взаимодействии между клиентом (браузером) и сервером (веб-сайтом). Он позволяет защитить пользовательские данные от прослушивания, перехвата и модификации на пути между устройством пользователя и сервером сайта.

Если попытаться открыть сайт через протокол HTTP , большинство современных браузеров выведут предупреждение о том, что соединение незащищённое, а в ряде случаев и вовсе откажется открывать подозрительный сайт. Это связано с тем, что HTTP передаёт данные в открытом виде, без шифрования, что делает их уязвимыми к атакам типа man-in-the-middle.

Man-in-the-middle (MITM) — это тип кибератаки, при котором злоумышленник вклинивается между двумя участниками общения , например «Клиент-Злоумышленник-Сервер».

Он может прослушивать трафик, модифицировать данные, перехватывать логины, пароли, токены, платёжные данные. К примеру, это может быть перехват данных через публичный Wi-Fi, а также:

DNS spoofing (или DNS poisoning) — это атака, при которой злоумышленник перехватывает запрос DNS-сервера и возвращает поддельный IP-адрес , перенаправляя жертву на вредоносный сайт вместо нужного. Защититься от этого можно при использовании DNSSEC (цифровые подписи для проверки ответов), подключении через DoH (DNS over HTTPS) или DoT (DNS over TLS), а также путём отказа от использования публичных DNS без шифрования (например, Google DNS без защиты).
DNSSEC — это набор расширений протокола DNS, добавляющих поддержку цифровых подписей , чтобы проверить подлинность и целостность DNS-ответов. Каждый DNS-ответ подписывается криптографическим ключом. Клиент проверяет подпись, чтобы убедиться, что ответ не был изменён.
DNS over HTTPS — это технология, при которой DNS-запросы отправляются через HTTPS , чтобы защитить их от прослушивания и манипуляций.
DNS over TLS — аналог DoH, но вместо HTTPS используется протокол TLS для шифрования DNS-запросов. DNS-запросы отправляются через защищённое TCP-соединение на порту 853.
ARP - spoofing (Address Resolution Protocol spoofing) — это атака в локальной сети, при которой злоумышленник притворяется другим устройством, чтобы перехватывать трафик между клиентом и шлюзом. Защититься можно через статические ARP-записи, внедрение порт-безопасности на коммутаторах (MAC limiting, sticky MAC) и использование шифрования (HTTPS, VPN), чтобы даже при MITM данные были защищены.
MAC Limiting — это функция коммутаторов, которая ограничивает количество MAC-адресов, которые могут использовать один физический порт. Защищает от злоумышленников, которые хотят подключить свой маршрутизатор/компьютер к вашей физической сети. Если вы установите лимит = 1, то только одно устройство может быть подключено к этому порту.
Sticky MAC — это функция коммутаторов, которая запоминает MAC-адреса, подключенных к порту устройств, и не позволяет другим устройствам использовать этот порт. Коммутатор запоминает MAC-адрес устройства, и если кто-то попытается подключиться с другим MAC — доступ будет заблокирован.
HTTPS stripping (понижение до HTTP) — это атака, при которой злоумышленник понижает соединение с HTTPS до HTTP, чтобы иметь возможность прослушивать трафик. Защита - установка заголовка HTTP Strict Transport Security (HSTS), редирект всех HTTP-запросов на HTTPS, использование HSTS preload list (в браузерах).
SSL stripping — более ранняя версия HTTPS stripping. Злоумышленник отбрасывает SSL/TLS-соединение, чтобы получить доступ к незашифрованному трафику. Это классическая MITM-атака , которая позволяет просматривать и изменять данные. Защита - HSTS, проверка сертификатов на клиенте, использование Public Key Pinning (HPKP), обучение пользователей обращать внимание на значок замочка в адресной строке.
HTTP Public Key Pinning — механизм, позволяющий сайтам указывать, какие публичные ключи SSL/TLS должны использоваться для их домена. Без HPKP, если злоумышленник получит сертификат от доверенного CA, он сможет обмануть браузер и выполнить MITM-атаку. Сервер отправляет заголовок Public-Key-Pins, где указаны хэши допустимых публичных ключей.

Чтобы защититься от MITM, нужно обеспечивать использование HSTS для принудительного HTTPS (HTTPS+HSTS), использовать проверенные, актуальные и самоподписанные SSL/TLS-сертификаты, проверять их цепочку доверия, а также можно шифровать данные end-to-end - тогда даже если трафик будет прослушиваться, без ключа будет бесполезен. На фронтенде можно использовать Content-Security-Policy (CSP).

HTTPS — это расширение протокола HTTP, которое использует технологию шифрования , чтобы обеспечить безопасный обмен данными между клиентом и сервером. Основой HTTPS является протокол TLS (Transport Layer Security) или его устаревшая версия SSL (Secure Sockets Layer).

SSL (Secure Sockets Layer) — устаревший протокол шифрования, который использовался ранее. Сейчас он считается небезопасным.

TLS (Transport Layer Security) — современный стандарт шифрования, который заменил SSL. В настоящее время используется TLS 1.2 и TLS 1.3.

Термин «SSL» до сих пор часто встречается в бытовом языке, хотя технически сейчас речь идёт именно о TLS.

Как работает:

Установка соединения - клиент и сервер обмениваются сертификатами.
Шифрование - данные шифруются с использованием симметричных и асимметричных алгоритмов.
Проверка целостности - используется HMAC для проверки целостности данных.

Применение:

HTTPS: защищенный веб-трафик.
SMTP, IMAP: безопасная передача электронной почты.
gRPC, WebSocket: безопасное взаимодействие микросервисов.

mTLS (Mutual TLS) — это расширение TLS, при котором обе стороны (клиент и сервер) аутентифицируют друг друга с помощью сертификатов. Это обеспечивает двустороннее доверие.

Как работает:

Клиент отправляет свой сертификат серверу.
Сервер проверяет сертификат клиента.
Сервер отправляет свой сертификат клиенту.
Клиент проверяет сертификат сервера.

OpenSSL — это криптографическая библиотека и набор инструментов для работы с протоколами SSL/TLS. Она используется для создания, управления и проверки сертификатов, а также для шифрования данных.

Работа HTTPS основана на технологии асимметричного шифрования, которая позволяет безопасно обмениваться данными даже по незащищённым каналам связи.

Клиент сначала отправляет запрос на сервер, предлагая поддерживаемые версии TLS и алгоритмы шифрования (такой этап называется запросом клиента, или Client Hello), а сервер выбирает наиболее подходящий набор параметров и отправляет свой SSL/TLS-сертификат вместе с открытым ключом (ответ сервера, Server Hello).

Клиент проверяет подлинность сертификата:

находится ли издатель (удостоверяющий центр) в списке доверенных;
не истёк ли срок действия сертификата;
совпадает ли доменное имя с адресом сайта.

С помощью открытого ключа клиента и закрытого ключа сервера генерируется сеансовый ключ для дальнейшего симметричного шифрования - это обмен ключами. Все последующие данные передаются уже в зашифрованном виде, используя сеансовый ключ.

SSL/TLS-сертификат — это цифровой документ, связывающий открытый ключ с идентичностью владельца сайта. Он содержит следующую информацию:

доменное имя сайта;
имя владельца или организации;
открытый ключ;
срок действия сертификата;
подпись удостоверяющего центра (CA);
информация об алгоритмах шифрования.

Сертификаты создаются и подписываются удостоверяющими центрами (CA — Certificate Authority), которые играют роль доверенной третьей стороны.

Для проверки подлинности сертификата используется цепочка сертификатов, состоящая из трёх уровней:

Корневой сертификат (Root CA), который создаётся и хранится самим удостоверяющим центром, и устанавливается в операционные системы и браузеры по умолчанию;
Промежуточный сертификат (Intermediate CA), который выпускается корневым центром и используется для выпуска конечных (серверных) сертификатов, позволяя избежать прямого использования корневого сертификата;
Серверный сертификат (Leaf или End-Entity Certificate), который выдаётся конкретному сайту и содержит информацию о домене и публичном ключе.

Браузер проверяет каждое звено этой цепочки, начиная с корневого сертификата, чтобы убедиться в её достоверности.

Сайты, работающие по протоколу HTTP, не обеспечивают шифрования. Это значит, что все данные (логины, пароли, номера карт и т. д.) передаются в открытом виде и могут быть легко перехвачены злоумышленником. Поэтому современные браузеры (например, Chrome, Firefox, Edge) помечают такие сайты как небезопасные , чтобы предупредить пользователей о рисках.

Большинство известных мировых удостоверяющих центров (например, DigiCert, Let’s Encrypt, Sectigo) находятся за пределами России. Для обеспечения суверенитета и безопасности в РФ были созданы собственные удостоверяющие центры, например Минцифры России (ранее Минкомсвязи), Центр сертификации ключей Минобороны и УЦ ФСБ.

Эти центры выдают национальные сертификаты , которые используются для защиты государственных и критически важных ресурсов. Однако такие сертификаты не доверяются по умолчанию зарубежными браузерами и операционными системами.

Поэтому, если открыть отечественный государственный сервис, браузер может не открыть страницу, и для этого нужно решить вопрос, связанный с тем, что сайт использует сертификат отечественного удостоверяющего центра:

Скачать корневой сертификат этого центра.
Установить его в хранилище доверенных корневых сертификатов операционной системы или браузера.
После установки сайт должен открыться без ошибок.

ACME (Automated Certificate Management Environment)— это протокол, который позволяет автоматически получать и обновлять сертификаты TLS от центров сертификации (например, Let's Encrypt). Он используется для безопасного шифрования трафика.

Let's Encrypt — это бесплатный центр сертификации, предоставляющий SSL/TLS-сертификаты для шифрования трафика. Он использует протокол ACME для автоматизации процесса получения сертификатов. Сертификаты действуют 90 дней.

Секретный ключ (Secret Access Key) — это компонент учетных данных, используемый для аутентификации и авторизации в облачных сервисах, API или других системах. Обычно он используется вместе с Access Key ID (идентификатором доступа). Это безопасное хранение ключей в Kubernetes Secrets или HashiCorp Vault.

Самоподписанный сертификат — это сертификат, который подписывается собственным приватным ключом, а не центром сертификации (CA). Он используется для тестирования или внутренних систем.

Сертификат - это цифровой документ, связывающий открытый ключ с идентичностью владельца. Он может быть связан не только с сайтами, но и с другими владельцами, чем служит при определении подлинности.

Удостоверяющий центр (CA) - это организация, выпускающая и подписывающая сертификаты.

Цепочка сертификатов - это последовательность сертификатов от корневого до серверного.

Асимметричное шифрование - это метод шифрования, использующий пару ключей — открытый и закрытый.

Симметричное шифрование - это шифрование, при котором используется один и тот же ключ для шифрования и дешифрования.

Сеансовый ключ - временный ключ, создаваемый для одного сеанса связи.

Безопасность приложений

Безопасность фронтенда

Фронтенд — это первая линия обороны. Он взаимодействует с пользователем, поэтому особенно уязвим.

Угроза	Решение
XSS (Cross-site Scripting)	Санитизация входных данных, применение Content Security Policy (CSP), использование современных фреймворков (React, Angular), экранирование всех динамически выводимых значений
CSRF (Cross-site Request Forgery)	Использование CSRF-токенов, установка атрибута SameSite для cookies, корректная настройка CORS
Clickjacking	Заголовки `X-Frame-Options` (например, `DENY` или `SAMEORIGIN`) и директивы CSP (`frame-ancestors`)
Небезопасные скрипты	Исключение подключения внешних JavaScript-библиотек из непроверенных или недоверенных источников
Утечка токенов авторизации	Хранение токенов в защищённых cookie с атрибутами `HttpOnly`, `Secure`, `SameSite=Strict` или `Lax`; избегать использования `localStorage`
CORS политики	Ограничение доменов, которым разрешено делать запросы к API, через заголовки `Access-Control-Allow-Origin` и другие CORS-заголовки
Произвольные скрипты и загрузка ресурсов из посторонних источников	Настройка Content Security Policy (CSP) для блокировки выполнения неавторизованных скриптов и загрузки ресурсов с недоверенных доменов

XSS (Cross-site Scripting) - это внедрение вредоносного кода на веб-страницу. Злоумышленник вставляет JS-скрипт, который выполняется в браузере жертвы. Может украсть токены, сессии, перенаправить пользователя.

Чтобы защититься от XSS, нужно экранировать всё, что выводится на страницу, использовать фреймворки, которые экранируют данные по умолчанию (React, Angular, Vue), добавить CSD, а также избегать использование innerHTML, eval() и dangerouslySetInnerHTML.

Санитизация - это очистка данных перед использованием или выводом. К примеру, Удаление потенциально опасных тегов (<script>, onerror, javascript:) из входящих данных. Используется при выводе пользовательского контента.

Content Security Policy (CSP) - это политика безопасности, ограничивающая выполнение скриптов. Браузер блокирует выполнение непроверенных скриптов и загрузку ресурсов со сторонних доменов. Помогает против XSS.

Escape всех выводимых значений - это экранирование специальных символов (<, >, & и др.). Предотвращает интерпретацию пользовательского ввода как HTML/JS. Например, «<b>» станет «<b>».

Clickjacking - это скрытое перехватывание действий пользователя. Злоумышленник встраивает ваш сайт в iframe и заманивает клики (например, «лайк», «войти»). Решается через X-Frame-Options и CSP.

CSRF токены - это случайные значения, проверяемые сервером. Сервер требует уникальный токен при POST-запросах, чтобы убедиться, что запрос отправил пользователь, а не злоумышленник.

SameSite-атрибуты cookies ограничивают отправку cookie в межсайтовых запросах. SameSite=Strict/Lax предотвращает автоматическую отправку токенов в запросах с других сайтов → защищает от CSRF.

CORS (Cross-Origin Resource Sharing) - политики доступа между доменами. Браузер блокирует запросы между разными доменами, если сервер не разрешил их явно. Защищает от несанкционированных API-вызовов.

Здесь важно отметить такие понятия, как origin и credentials.

Origin (источник) - это домен, с которого был сделан запрос. Например, Запрос из https://evil.com к https://bank.com имеет origin: https://evil.com.

Credentials (учётные данные) - это информация, которая может быть передана в запросе - куки, авторизованные заголовки, сертификаты клиента.

CORS-политики как раз работают с этими понятиями:

Политика	Что делает
`Access-Control-Allow-Origin: *`	Разрешает доступ к ресурсу со всех источников (доменов). При использовании значения `*` нельзя одновременно разрешать передачу учётных данных (credentials), так как это противоречит спецификации CORS.
`Access-Control-Allow-Credentials: true`	Указывает браузеру, что при запросе могут передаваться учётные данные (cookies, HTTP-аутентификация). Требует указания конкретного домена в `Access-Control-Allow-Origin` (значение `*` недопустимо).
`withCredentials: true`	Флаг в JavaScript (в объектах `fetch` или `XMLHttpRequest`), позволяющий включать учётные данные в кросс-доменные запросы. Работает только если сервер явно разрешает credentials через заголовок `Access-Control-Allow-Credentials: true`.

К примеру, в fetch API это будет так:

fetch('https://api.example.com/data',  {
    method: 'GET',
    credentials: 'include'
});

Небезопасный скрипт - внешние JS-файлы из непроверенных источников. Такие скрипты могут содержать вредоносный код. Лучше использовать CDN известных библиотек, а не случайные ссылки.

Непроверенный источник - использование внешних библиотек без верификации. Нужно проверять пакеты, использовать Snyk/Dependabot, не подключать JS/CSS с подозрительных сайтов.

Утечка токенов авторизации - сохранение токена в localStorage или URL. Токен можно украсть через XSS или историю браузера. Лучше хранить в httpOnly+secure cookie.

localStorage - это хранилище в браузере. Не защищено от XSS → не стоит хранить токены здесь. Подходит только для нечувствительной информации.

httpOnly - это атрибут cookie, запрещающий доступ из JavaScript. Предотвращает кражу токенов через XSS.

secure - это атрибут cookie, требующий HTTPS. Cookie будет передаваться только через защищённое соединение.

SameSite=Strict / Lax ограничивает отправку cookie в междоменных запросах. Strict: только свои домены. Lax: разрешает GET-запросы с других сайтов.

Strict - самый трогий режим SameSite. Cookie отправляются только при переходе внутри сайта.

Lax - более мягкий режим SameSite. Разрешает GET-запросы с других сайтов (например, ссылки).

Безопасность бэкенда

Бэкенд — «сердце» приложения. Здесь сосредоточена основная логика и доступ к данным.

Угроза	Решение
SQL Injection	Использование ORM или параметризованных запросов для отделения кода от данных, исключающих выполнение произвольного SQL-кода.
Insecure Direct Object References (IDOR)	Проверка прав доступа пользователя к запрашиваемому объекту перед его выдачей, независимо от переданного идентификатора.
Неправильная обработка ошибок	Исключение вывода деталей стека, внутренних путей или конфигураций клиенту; использование обобщённых сообщений об ошибках в production.
Аутентификация и авторизация	Применение стандартных протоколов (JWT, OAuth2, SAML), проверка ролей и прав, реализация моделей управления доступом (например, RBAC).
Rate Limiting	Ограничение количества запросов от одного клиента за определённый период для предотвращения атак типа brute-force и DDoS.
Валидация входных данных	Строгая проверка всех входящих данных на соответствие ожидаемому формату, типу, диапазону и длине, включая фильтрацию потенциально опасных символов.
Подозрительная активность	Полное логирование действий пользователей, анализ аномалий, интеграция с системами SIEM для централизованного мониторинга и оповещения.
Обновление зависимостей	Регулярный аудит используемых библиотек на наличие уязвимостей с помощью инструментов вроде Snyk, Dependabot или OWASP Dependency-Check.
Защита файловых загрузок	Проверка MIME-типа, расширения, размера файла; сохранение файлов вне корневой директории сервера; изоляция исполняемого контекста.
Работа с сессиями	Использование cookie с флагами `HttpOnly`, `Secure`, `SameSite`; короткий срок жизни сессионных токенов; регулярное обновление идентификаторов сессий.

Параметризованные запросы - это механизм работы с SQL-запросами, где пользовательские данные не встраиваются напрямую в SQL, а передаются отдельно. Это защита от SQL Injection (SQLi) — одной из самых опасных уязвимостей. Рекомендуется использовать ORM, и всегда использовать параметры вместо подстановки строк.

# ❌ Плохо: конкатенация
query = f"SELECT * FROM users WHERE id = {user_id}"

# ✅ Хорошо: параметризованный запрос
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

IDOR (Insecure Direct Object Reference) - это уязвимость, при которой пользователь может получить доступ к ресурсам, к которым он не имеет прав, просто изменяя ID в URL или теле запроса.

Пример:

GET /api/user/123 → GET /api/user/456

Если сервер не проверяет права — можно получить чужие данные. Поэтому лучше проверять принадлежность объекта текущему пользователю, использовать UUID вместо числовых ID и логировать попытки несанкционированного доступа.

Stack traces (трассировки стека) - подробное описание ошибок, включая имя класса, метода, строки кода. Злоумышленник получает информацию о внутренней реализации, что помогает ему находить уязвимости. Для защиты нужно не показывать stack trace на боевых системах, использовать общие сообщения об ошибках: Internal Server Error, Access Denied, и логировать ошибки на сервере, но не отправлять детали клиенту.

Детали реализации - это любая информация, которая раскрывает технологическую реализацию : версии библиотек, пути, заголовки, сообщения об ошибках. Помогает злоумышленнику найти известные уязвимости в конкретных версиях ПО. Как защитить? Убирать заголовки типа Server, X-Powered-By. Не выводить информацию о технологиях в ответах. Использовать reverse proxy (Nginx, Traefik), чтобы скрыть backend.

Rate Limiting (Ограничение частоты запросов) - ограничение количества запросов от одного пользователя или IP за определённый период. Это защищает от брут-форса, DDoS и автоматизированных сканеров, выдавая «Too many requests».

DDoS (Distributed Denial of Service) - это атака, при которой сервер перегружается множеством запросов, чтобы сделать его недоступным. Множество устройств (ботнет) шлёт запросы на ваш сервер, сервер же не выдерживает нагрузку и падает. Чтобы от этого защититься, нужно использовать CDN (Cloudflare, AWS Shield), WAF (Web Application Firewall), Rate-limiting, облако с автоматическим масштабированием и конечно DDoS-защиту провайдера.

Brute-force атаки - это подбор логина/пароля, токена, ID и т.д. через массовые запросы. Встречается при авторизации, API с предсказуемыми ID, токенами восстановления пароля. Защита достигается через Rate limiting, CAPTCHA после нескольких неудачных попыток, двухфакторную авторизацию (MFA) и невозможность угадать токен (если использовать случайные значения).

CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) — это тест, который позволяет отличить человека от бота. Используется для защиты от автоматизированных действий: регистрации, авторизации, отправки форм и т.д.

Типы CAPTCHA:

Text CAPTCHA - ввод текста с искажённого изображения
reCAPTCHA v2 / v3 - Google reCAPTCHA («Я не робот», Invisible CAPTCHA)
hCaptcha - альтернатива reCAPTCHA
Checkbox CAPTCHA - простая галочка «Я не робот»
No CAPTCHA - поведенческий анализ (reCAPTCHA v3)

CAPTCHA, конечно, не защищает от продвинутых ботов, иногда требует JS или куки, а также может мешать UX.

Валидация входных данных - это проверка всех входящих данных на корректность, безопасность и допустимые значения. Это строгая валидация типов (isEmail, isInt), очистка и нормализация данных, использование специальных библиотек.

Strict validation (строгая валидация) - это не просто «что-то пришло», а проверка точного формата, типа и диапазона значений. Это предотвращает подмену данных, упрощает тестирование и защищает от непредвиденных ситуаций.

Подозрительная активность - это необычное поведение: много запросов, попытки подобрать ID, странная геолокация, нестандартные User-Agent'ы и т.д. Мониторить её нужно, чтобы выявлять возможные атаки, предотвращать инсайдерские угрозы и отслеживать утечки учётных записей. Используется через логирование всех действий, интеграцию с SIEM и настройку алертов (например, на 10+ неудачных авторизаций.

SIEM (Security Information and Event Management) - это система сбора, анализа и реагирования на события безопасности. Нужно для централизованного логирования, обнаружения аномалий, аудита действий пользователей, реагирования на инциденты.

Обновление зависимостей - это регулярная проверка и обновление библиотек, фреймворков и компонентов. Большинство уязвимостей - в зависимостях. Защититься можно через автоматические проверки, CI/CD интеграцию и сканеры SCA.

Software Composition Analysis (SCA) — это процесс анализа зависимостей в проекте с целью выявления уязвимостей, лицензионных проблем и устаревших компонентов. Современные приложения используют сотни и тысячи open-source библиотек . Если они содержат уязвимости — ваше приложение тоже уязвимо.

SCA-инструменты - это:

Snyk;
Dependabot;
OWASP Dependency Check;
Sonatype Nexus IQ;
WhiteSource / BlackDuck.

Snyk - это инструмент для поиска уязвимостей в зависимости и контейнерах. Он позволяет выполнять поиск CVE в npm, pip, Maven и т.д., позволяет интегрироваться с GitHub, CI/CD, предлагает патчи.

CVE (Common Vulnerabilities and Exposures) — это стандартизированный список известных уязвимостей в программном обеспечении. Каждой уязвимости присваивается уникальный идентификатор вида CVE-YYYY-XXXXX.

CVSS — Common Vulnerability Scoring System - это оценка уязвимости от 0 до 10, где 9-10 критическая, 7-8.9 высокая, 4-6.9 средняя, 0-3.9 низкая.

Dependabot - это интеграция в GitHub, которая автоматически обновляет зависимости и сообщает о уязвимостях. Поддерживает Docker, NuGet, Composer, позволяет обновлять package.json, requirements.txt и прочее.

webroot - это корневая директория сайта, откуда отдаются файлы. Нельзя выходить выше webroot, а в этой директории не нужно хранить чувствительные файлы (.env, .git, config.php и т.д.). Для защиты лучше не давать возможность листинга директорий, переносить чувствительные файлы вне папки webroot и использовать .htaccess / nginx.conf для ограничений.

Cookie-флаги - это настройки cookie, которые делают их более безопасными.

HttpOnly запрещает чтение cookie из JS → защищает от XSS;
Secure передаёт Cookie только через HTTPS;
SameSite=Strict/Lax ограничивает отправку cookie в междоменных запросах;
Max-Age / Expires устанавливает время жизни;
Path / Domain ограничивает область действия.

Что важно добавить в проект для безопасности

Что важно добавить в проект для безопасности?

Компонент	Что добавить
Сервер	Настройка HTTPS, использование WAF (Web Application Firewall), конфигурация файрвола, rate limiting, мониторинг состояния системы, централизованное логирование
API	Реализация авторизации, принцип наименьших привилегий, строгая валидация входных данных, ограничение частоты запросов, поддержка актуальной документации (например, OpenAPI)
База данных	Шифрование данных (в покое и в движении), выдача минимально необходимых привилегий, защита от SQL-инъекций, регулярное резервное копирование и проверка восстановления
Авторизация	Поддержка MFA, использование безопасных токенов (JWT/OAuth2), механизм refresh-токенов, реализация выхода из системы, политика сложных паролей
Файлы и загрузки	Проверка типа и расширения файлов, изоляция среды хранения, ограничение размера загрузки, сканирование на вирусы и вредоносный код
Пользовательский ввод	Санитизация и нормализация данных, строгая валидация, экранирование выводимого контента, применение Content Security Policy (CSP)
Сервисы и зависимости	Использование актуальных версий библиотек, анализ состава ПО (SCA), автоматическое отслеживание уязвимостей, регулярные обновления
CI/CD	Интеграция анализа уязвимостей (SAST, SCA), автоматизированное тестирование безопасности, проверка конфигураций, сборка в изолированной среде
Работа с данными	Минимизация объёма собираемых данных, шифрование конфиденциальной информации, соблюдение сроков хранения, безопасное удаление устаревших данных
Инциденты	Разработка и поддержка плана реагирования на инциденты, процедуры уведомления пользователей и регуляторов, взаимодействие с CERT и другими организациями по кибербезопасности

WAF (Web Application Firewall) — это специализированный файрвол для защиты веб-приложений от атак уровня приложения (например, XSS, SQLi, CSRF). Анализирует HTTP-запросы, блокирует подозрительные запросы до того, как они достигнут бэкенда. Может быть облачным (Cloudflare, AWS WAF) или локальным (ModSecurity).

Файрвол — это система фильтрации сетевого трафика на уровне IP/портов. Stateful firewall отслеживает состояние соединений, Stateless firewall работает с правилами без учёта состояния, а Application Layer Firewall обеспечивает фильтрацию на уровне приложения (WAF чаще всего).

Входящий трафик → проверяется правилами → пропускается или блокируется

Минимальные привилегии (Principle of Least Privilege) подразумевают, что каждый пользователь, процесс или сервис должен иметь минимально возможные права, чтобы выполнять свою задачу. Всегда лучше «недодать», чем «переборщить». Это предотвратит распространение угроз внутри системы, несанкционированный доступ и утечки данных. К примеру. пользователь не может удалять таблицы, сервис запускается без прав root, а администратор не имеет доступа ко всем данным.

RBAC (Role-Based Access Control) - это ролевое управление доступом, где доступ к данным и функциям зависит от роли пользователя.

ABAC (Attribute-Based Access Control) - это атрибут-ориентированное управление доступом, где доступ зависит от характеристик (атрибутов) пользователя, объекта и среды.

IAM (Identity and Access Management) - это система управления удостоверениями и правами доступа . Она обеспечивает аутентификацию (кто ты), авторизацию (что ты можешь) и аудит (что ты сделал).

Refresh tokens - это токены, используемые для обновления короткоживущих access токенов, чтобы не требовать повторного входа пользователя.

Login → получаем short-lived access token + long-lived refresh token

Когда access истекает → отправляем refresh → получаем новый access

Важно: если утекает refresh token → злоумышленник может получить доступ на долгое время.

Экранирование (Escaping) - это преобразование специальных символов в безопасную форму, чтобы они не интерпретировались как код. Используется для безопасного вывода HTML/JS и санитизации входных данных, а также для предотвращения XSS.

Минимизация сбора подразумевает не собирать больше, чем необходимо. Это один из принципов GDPR, CCPA и других регуляций. К примеру, не собирать номер паспорта, если он не нужен, не хранить пароли в открытом виде и удалять данные после окончания их жизненного цикла. Это снижает риск утечки, соответствует законодательству и упрощает управление данными.

GDPR (General Data Protection Regulation) - это европейский закон о защите персональных данных, действует с 2018 года . Регулирует сбор, обработку и хранение персональной информации граждан ЕС.

Принципы:

Данные можно собирать только с согласия пользователя;
Пользователь может потребовать удалить свои данные;
Пользователь может запросить выгрузку своих данных;
В случае утечки — уведомить регулятора в течение 72 часов;
Собирать только то, что необходимо;
Назначается при определённых объемах обработки.

Американский аналог GDPR, CCPA (California Consumer Privacy Act) действует в Калифорнии с 2020 года. Защищает права жителей штата на контроль над своими данными.

Основные положения:

Пользователь может узнать, какие данные собираются;
Пользователь может попросить удалить его данные;
Запрет на продажу персональных данных без согласия;
Нельзя наказывать пользователей за использование прав.

В РФ нет полного аналога GDPR или CCPA, но есть базовые права и Федеральный закон №152-ФЗ «О персональных данных».

Основные положения:

персональные данные - это любая информация, относящаяся к определённому физическому лицу (ФИО, телефон, email, ИНН и т.д.);
согласие на обработку обязательно, если только данные не попадают под исключения (например, публичные данные);
оператор персональных данных - это организация или ИП, которые собирают и обрабатывают персональные данные;
с 2015 года российские пользователи должны иметь свои данные, сохранённые на серверах в РФ;
нет обязательного требования на уведомление об утечке;
субъект персональных данных имеет право на доступ, исправление и удаление своих данных.

Безопасность в разных языках

Что важно учесть при настройке безопасности в разных языках?

Язык	Особенности безопасности
JavaScript (Node.js)	Использование `Helmet` для безопасных HTTP-заголовков, `sanitize-html` для очистки HTML, `cors` и `helmet-csp` для управления политиками; избегать `eval()` и других функций с динамическим выполнением; контроль зависимостей в `npm` на наличие уязвимостей
Python (Django, Flask)	Django предоставляет встроенную защиту от XSS и CSRF; в Flask необходимо подключать защиту вручную; использовать `python-dotenv` для управления конфигурацией; проверка `pip`-пакетов на уязвимости через инструменты вроде `safety` или `bandit`
Java (Spring Boot)	Применение `Spring Security` для аутентификации и авторизации; использование `OWASP Dependency-Check` для анализа уязвимостей в зависимостях; генерация криптографически стойких случайных значений через `SecureRandom`; работа с шифрованием через Java Cryptography Architecture (JCA)
PHP	Использование `PDO` с подготовленными выражениями вместо устаревших `mysql_*` функций; хеширование паролей через `password_hash()`; экранирование вывода с помощью `htmlspecialchars()`; ограничение доступа через `.htaccess`
Ruby (Ruby on Rails)	Встроенная защита от XSS и CSRF; использование `strong parameters` для фильтрации входных данных; автоматическое экранирование вывода в шаблонах
Go	Работа с безопасностью на уровне middleware в `net/http`; использование параметризованных запросов через `sql.DB`; применение стандартного пакета `crypto/*` для шифрования; реализация собственных механизмов защиты при необходимости
C# (.NET Core)	Использование `ASP.NET Identity` для управления пользователями; `Data Protection API` для шифрования данных; `Anti-Forgery Tokens` для защиты от CSRF; Entity Framework с параметризованными запросами снижает риски SQL-инъекций
Rust	Высокий уровень контроля за памятью и безопасность на этапе компиляции; отсутствие типичных уязвимостей, связанных с переполнением буфера; рекомендуется использовать проверенные и безопасные crates из `crates.io`

Helmet - библиотека для Node.js, которая устанавливает важные HTTP-заголовки безопасности.

sanitize-html - библиотека в JavaScript для очистки HTML от небезопасных тегов и скриптов.

eval() - функция в JavaScript, которая выполняет строку как код. Рекомендуется её никогда не использовать, а при необходимости для JSON применять JSON.parse(). В идеале нужно санитизировать всё, что попадает в eval, если без него не обойтись.

npm-пакет - это библиотеки, доступные через npm (Node Package Manager). Многие пакеты содержат уязвимости, поэтому лучше проветь CVE. Кроме того, важно отметить ещё одну вещь. Пакеты могут быть компрометированы (dependency confusion, typosquatting).

Dependency Confusion - это когда злоумышленник публикует пакет с таким же названием, как у внутреннего приватного пакета, но с более высокой версией. При установке зависимостей система может выбрать вредоносный пакет вместо нужного. К примеру, проект использует mycompany-utils@1.0.0 (приватный), а злоумышленник публикует mycompany-utils@1.0.1 в npm / PyPI / NuGet. При установке зависимостей — загружается вредоносный пакет. Чтобы защититься, лучше проверять зависимости, не использовать пакеты с подозрительными именами. Как правило, IDE сейчас предупреждают, что пакеты сомнительные.

Typosquatting - это когда злоумышленник публикует пакет с похожим именем на популярную библиотеку, чтобы разработчики ошиблись и установили его. К примеру, вы хотели установить requests, но набрали request → получили вредоносный пакет. Чтобы защититься, нужно следить за опечатками при установке, проверять рейтинги и количество загрузок, использовать инструменты для проверки пакетов.

python-dotenv - инструмент для загрузки переменных окружения из файла .env. В Git важно не коммитить этот файл, используя .gitignore. Это файл для хранения чувствительной информации вне кода для удобства настройки разных сред (dev, prod).

pip-пакеты - это Python-библиотеки, установленные через pip. Уязвимые версии пакетов могут вызвать проблемы, и иногда пакеты могут содержать вредоносный код. Существуют специальные команды вроде pip-audit, audit, snyk test --python для проверки.

Spring Security - это платформа Spring для реализации аутентификации, авторизации и защиты веб-приложений.

OWASP Dependency-Check - это инструмент для анализа зависимостей и поиска известных уязвимостей (CVE). Может использоваться в разных системах, запускается через dependency-check.sh.

SecureRandom - это класс в Java для генерации криптографически безопасных случайных чисел. Его можно использовать для генерации токенов, паролей, солей. Math.random() предсказуем и не подходит для генерации такой информации.

Соль (salt) - это случайная строка, добавляемая к паролю перед хэшированием, чтобы сделать одинаковые пароли уникальными.

Пример:

String password = "password123";
String salt = generateSecureSalt(); // SecureRandom
String hashed = hashWithSalt(password, salt);

Java Cryptography Architecture (JCA) - это API Java для шифрования, подписей, хэширования и других криптографических операций. PDO - это PHP Data Objects для работы с БД, поддерживающие параметризованные запросы. Защищает от SQLi, поддерживает разные СУБД. ASP.NET Identity - это фреймворк Microsoft для управления пользователями, аутентификацией и авторизацией.

IdentityServer — это фреймворк для реализации аутентификации и авторизации в .NET , поддерживающий стандарты OAuth 2.0, OpenID Connect (OIDC), SAML. Используется для выдачи токенов, проверки подлинности, управления клиентами и ресурсами.

Anti-Forgery Tokens - это механизм защиты от CSRF-атак в ASP.NET. Сервер генерирует уникальный токен. Клиент должен отправить его обратно при POST-запросах.

Forgery — это попытка подделки запроса от имени пользователя, например, через CSRF (Cross-Site Request Forgery). Антифорджери токен как раз обеспечивает генерацию уникального токена для отправки вместе с запросом. Если токена нет или он неверен, запрос блокируется.

Низкоуровневый контроль подразумевает работу с памятью, буферами, указателями, это особенно актуально в языках вроде C/C++, Rust, Go. Именно такой контроль отвечает за переполнение буфера, чтение данных из чужой области памяти, использование небезопасных блоков. Для слежения за буферами нужно использовать безопасные методы работы с данными, языки с защитой от переполнения (Rust, Go), валидировать размеры входящих данных.

«Safe» крейты в Rust — библиотеки, написанные на безопасном Rust, без использования unsafe блоков.

Защита API

Как защитить API?

Ограничение частоты запросов (Rate Limiting) подразумевает жёсткое ограничение на количество запросов в единицу времени. Если лимит превышается — клиент получает ошибку 429 Too Many Requests. К примеру, максимум 1000 запросов в час.

Реализовать можно через Redis+middleware, Nginx limit_req_zone и API Gateway (AWS, Kong, Tyk).

API Gateway - это сервис, который выступает единым входом для всех ваших микросервисов или API, обеспечивая аутентификацию, авторизацию, rate limiting, логирование, трансформацию запросов и кэширование.

Популярные решения API Gateway:

Решение	Возможности
AWS API Gateway	Полностью управляемый сервис от Amazon Web Services для создания, публикации и управления API; встроенные функции аутентификации, авторизации, мониторинга, rate limiting и интеграции с Lambda
Kong	Открытый API-шлюз на основе NGINX с поддержкой плагинов: аутентификация (JWT, OAuth2), ограничение частоты запросов, логирование, трансформация запросов; масштабируемость и расширяемость
Tyk	Open-source API Gateway с возможностью использования в составе enterprise-платформы; поддержка rate limiting, аналитики, JWT, OAuth2, webhook-триггеров и централизованного управления через dashboard
Azure API Management	Управляемое решение Microsoft для публикации, защиты, анализа и масштабирования API; интеграция с Azure Active Directory, политиками преобразования и шифрования, SLA-гарантии
Traefik	Современный reverse proxy и API Gateway с поддержкой микросервисов; автоматическое обнаружение сервисов (через Docker, Kubernetes и др.); встроенные функции балансировки, TLS, middleware для аутентификации и rate limiting
NGINX Plus	Коммерческая версия NGINX с расширенными возможностями: продвинутое управление трафиком, rate limiting, JWT-аутентификация, мониторинг, поддержка gRPC и WebSocket

Redis + middleware (Node.js, Python, Go) подразумевает использование Redis как хранилища для отслеживания количества запросов от клиента. Middleware проверяет лимиты перед выполнением обработки.

Nginx limit_req_zone - это модуль Nginx, позволяющий ограничивать частоту запросов на уровне reverse proxy / load balancer.

Троттлинг (Throttling) - мягкая форма контроля частоты запросов. Если клиент выходит за пределы нормального поведения — его запросы замедляются, но не блокируются полностью. Пример:
- До 500 запросов в минуту – нормально;
- Более 500 – замедление ответа;
- Более 1000 – блокировка.

Это более гибкий контроль нагрузки, и реализуется через алгоритмы Token Bucket, Leaky Bucket, Redis+очередь и API Gateway.

Token Bucket («Ведро с токенами») работает так:

В «ведре» есть определённое число токенов;
На каждый запрос забирается один токен;
Если токенов нет → отказ;
Ведро наполняется со временем.

Leaky Bucket («Протекающее ведро»):

Запросы ставятся в очередь (ведро)
Ведро «протекает» с фиксированной скоростью
Если очередь заполнена → запросы отбрасываются

Инструменты мониторинга. Это системы, которые собирают метрики, логи и события из API, чтобы обнаруживать аномалии и реагировать на инциденты.

Инструмент	Возможности
Datadog	Комплексный платформенный инструмент для сбора метрик, логов, трассировки (APM), мониторинга безопасности (SIEM) и анализа производительности приложений
AWS CloudWatch	Управляемый сервис AWS для сбора метрик, логов и установки оповещений в рамках облачной инфраструктуры Amazon
Prometheus + Grafana	Prometheus — система сбора и хранения временных рядов; Grafana — визуализация метрик. Используется для мониторинга микросервисов и инфраструктуры
ELK Stack (Elasticsearch, Logstash, Kibana)	Решение для централизованного сбора, индексации и анализа логов: Logstash — агрегация, Elasticsearch — хранение и поиск, Kibana — визуализация
Grafana Loki	Лёгковесная система сбора и хранения логов, оптимизированная для интеграции с Grafana и работы с метками (labels), без индексации содержимого логов
New Relic	Платформа для мониторинга производительности приложений (APM), обнаружения ошибок, анализа безопасности и отслеживания пользовательского поведения

Как использовать мониторинг для безопасности?

Отслеживание аномальных запросов (например, много 4xx);
Обнаружение DDoS по пикам нагрузки;
Выявление подозрительных IP или пользователей;
Логирование всех действий с возможностью поиска.

Сложные ID (UUID вместо числовых ID). Вместо простых числовых ID (/user/1, /order/2) использовать уникальные и непредсказуемые значения, например:

/user/6ba7b810-9dad-11d1-80b4-00c04fd430c8

Это предотвратит IDOR, скроет структуру системы от злоумышленников и уменьшит возможность перебора. Для реализации надо генерировать UUID v4 при создании объекта, использовать их как первичные ключи или внешние идентификаторы.

Ограничение доступа к API и контроллерам. Это контроль того, кто может вызывать определённые эндпоинты и как часто. Существуют следующие практики:

Техника	Описание
RBAC / ABAC	Модели управления доступом: ролевая (RBAC — на основе ролей) и атрибутная (ABAC — на основе набора атрибутов пользователя, ресурса и контекста)
API Keys	Ключи для идентификации и авторизации клиентских приложений; требуют безопасного хранения и регулярной ротации
JWT / OAuth2	Стандарты токенов: JWT содержит подписанные данные (включая роль и срок действия), OAuth2 — протокол делегирования авторизации
IP Whitelisting	Ограничение доступа к API только с доверенных IP-адресов или диапазонов
Scope-based access	Предоставление доступа к ресурсам в соответствии с областью (scope), например, `read:users`, `write:documents`
WAF	Web Application Firewall фильтрует входящий трафик, блокируя запросы, содержащие признаки атак (XSS, SQLi, сканирование и др.)

Другие способы защиты API.

Мера	Описание
HTTPS	Все HTTP-запросы должны передаваться по зашифрованному каналу TLS
CORS политики	Настройка заголовков `Access-Control-Allow-Origin` и других CORS-атрибутов для разрешения запросов только с доверённых доменов
Authentication & Authorization	Реализация механизмов аутентификации (JWT, OAuth2, API Keys) и проверки прав доступа
Валидация входных данных	Проверка всех входящих данных на соответствие формату, типу и диапазону значений
Экранирование вывода	Преобразование специальных символов для предотвращения выполнения произвольного кода (например, XSS)
Проверка заголовков и параметров	Исключение передачи конфиденциальной информации через URL-параметры или незащищённые заголовки
Логирование и аудит	Фиксация всех значимых операций с возможностью последующего анализа и расследования инцидентов
Rate limiting + Throttling	Ограничение количества запросов от одного клиента для защиты от brute-force и DDoS-атак
Обновление зависимостей	Регулярный аудит библиотек с помощью Snyk, Dependabot и аналогичных инструментов
Интеграция с WAF	Размещение WAF перед API для фильтрации вредоносного трафика на границе сети
Работа с токенами	Использование безопасных cookie-флагов (`HttpOnly`, `Secure`, `SameSite`), короткий TTL для access-токенов, использование refresh-токенов
Rate limiting по IP / User-Agent / Token	Многоуровневое ограничение частоты запросов на основе различных идентификаторов
Географические ограничения	Блокировка или дополнительная верификация запросов из регионов, где сервис официально не используется

Как выглядит защищённый API-запрос?

GET /api/users/me HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
User-Agent: MyApp/1.0
Accept: application/json
Origin: https://trusted-origin.com 

На сервере проверяется токен, проверяется origin через CORS, логируется запрос, проверяется rate limit, права доступа, а ответ шифруется через HTTPS.

Контроль и отслеживание

Отслеживание действий, перехват и защита конфиденциальности подразумевает процесс логирования, мониторинга и анализа активности внутри системы для выявления подозрительных действий и обеспечения конфиденциальности данных.

Это нужно для обнаружения несанкционированного доступа, требуется для соблюдения GDPR/CCPA/152-ФЗ, используется для расследования инцидентов и аудита изменений.

Как реализовать?

Логирование всех действий. Все операции с данными, входы, изменения прав.
Мониторинг в реальном времени. Используется при помощи SIEM, Datadog, ELK.
Шифрование трафика. Используется с HTTPS, TLS, end-to-end encryption.
Анонимизация логов подразумевает отказ от хранения персональных данных напрямую.
RBAC / ABAC для разграничения прав.
Audit trail - журнал изменений.

Какие инструменты используются?

SIEM (Security Information and Event Management) : Splunk, QRadar, Graylog;
User and Entity Behavior Analytics (UEBA) : анализ поведения;
ELK Stack : Elasticsearch + Logstash + Kibana;
Datadog Security Monitoring;
AWS CloudTrail / Azure Monitor.

Контроль включает в себя не только изучение и мониторинг, но и своевременное реагирование. Здесь важно выделить аварийное восстановление (Disaster Recovery Plan, DRP) - план действий, позволяющий восстановить работу сервиса после катастрофы, такой как сбой оборудования, утечка данных, DDoS, взлом, природная катастрофа.

Основные этапы плана по аварийному восстановлению:

Подготовка – обучение команды, документация, резервные копии;
Обнаружение – обнаружение проблемы через мониторинг;
Ограничение ущерба – изоляция систем, откат до безопасного состояния;
Восстановление – загрузка бэкапов, патчи, переключение на standby-серверы;
Уроки – анализ инцидента, обновление процедур.

DRP включает в себя список ответственных лиц, процедуру восстановления (ручную и автоматическую), точки восстановления, время восстановления, бэкапы (локальные+облачные) и проверку плана. Контроль как раз подразумевает, что этот план должен быть работоспособным.

Точки восстановления (RPO, Recovery Point Objective): данные могут быть потеряны максимум за 1 час;
Время восстановления (RTO, Recovery Time Objective): система должна восстановиться за 2 часа.

Контроль угроз и уязвимостей же включает в себя регулярный поиск, оценка и устранение уязвимостей в коде, зависимостях и инфраструктуре.

Инструменты:

Тип	Инструменты
SAST (Static Application Security Testing)	SonarQube, Bandit, Checkmarx
DAST (Dynamic Application Security Testing)	OWASP ZAP, Burp Suite, Nuclei
SCA (Software Composition Analysis)	Snyk, Dependabot, OWASP Dependency-Check
IAST (Interactive Application Security Testing)	Contrast Security, Seeker
Vulnerability Scanning	Nessus, OpenVAS, Qualys
Threat Intelligence	VirusTotal, AlienVault OTX, Mandiant

Контроль трафика включает использование WAF для блокировки XSS, SQLi, фильтрацию запросов через CORS, CSP, rate limiting и DDoS-защиту (Cloudflare, AWS Shield, Radware). Аудит и мониторинг включает логирование всех событий, анализ, алерты на подозрительную активность, регулярные отчёты. Важно также отметить IDPS (Intrusion Detection & Prevention System). IDS обнаруживает подозрительную активность, а IPS автоматически блокирует угрозы.

Отслеживание действий

Особенно актуально когда выполняется контроль и мониторинг в корпоративной сети, к примеру, когда осуществляется удалённый доступ через VPN.

Как организовать безопасный удалённый доступ и что можно отслеживать?

Как устроена типичная схема.

Удалённый пользователь → Подключается к VPN → становится частью внутренней сети → Получает доступ к:
	- Файловому серверу
	- Домену (Active Directory)
	- Внутренним сервисам (например, ERP, CRM)

Здесь основными компонентами будут:

VPN-сервер (например, OpenVPN, WireGuard, Microsoft RRAS)
Файловый сервер (например, Windows Server + SMB или NAS)
Active Directory / LDAP
Групповая политика (GPO)
Мониторинг активности
Антивирус / EDR

Что можно отслеживать?

Всё, что делает пользователь внутри домена, можно логировать и анализировать, если настроить правильно.

Тип активности	Что можно отследить	Инструменты
Посещаемые сайты	Все HTTP/HTTPS-запросы через прокси или transparent proxy	Squid, Zscaler, Cisco Talos Intelligence
Загрузка файлов	Кто, что скачал, скопировал, удалил	File Server Resource Manager (FSRM), EDR
Использование USB-устройств	Что подключалось, какие файлы копировались	GPO, DLP, Endpoint Security
Программы, которые запускает пользователь	Имя процесса, путь, PID	Sysmon, EDR, SIEM
Созданные процессы, команды в CMD/PowerShell	Полный список запущенных процессов и команд	Sysmon, PowerShell logging, EDR
Входы и выходы из системы	Когда вошёл, с какого IP, длительность сессии	Event Viewer, SIEM, Active Directory Logs
Изменения в системе	Изменение политик, прав доступа, записей реестра	Auditpol, Sysmon, GPO
DNS-запросы	Какие домены запрашивал пользователь	DNS Logging, Windows Event Logs
Сетевой трафик	С кем общается клиент, порт, протокол	Wireshark, Zeek (Bro), Suricata
Email-активность	Отправка/чтение писем (при использовании Exchange)	Exchange logs, mail tracking

Что может видеть администратор при полном контроле?

Пользователь сделал	Что может знать администратор
Заходит через VPN	Логин, IP-адрес, время входа, тип устройства
Перешёл на сайт	Факт запроса зафиксирован в логах прокси или WAF
Скопировал файл с сервера	Данные о пользователе, файле, целевом расположении и времени операции — доступны в FSRM или DLP
Запустил powershell.exe с вредоносным скриптом	Подробная запись выполнения команд в логах Sysmon или PowerShell
Подключил флешку и скопировал данные	Устройство распознано системой; действия залогированы через GPO или DLP
Открыл документ Word и сохранил его	Возможность отслеживания изменений при использовании DLP или совместного хранения (SharePoint)
Попытался получить доступ к запрещённой папке	Запись события в Event Viewer, автоматическое оповещение в SIEM
Вызвал cmd.exe и попытался выполнить команду	Логирование через Sysmon и политики групповой безопасности (GPO)
Отправил email с конфиденциальной информацией	Обнаруживается и блокируется с помощью решений DLP

Что реально можно реализовать в компании?

Возможности отслеживания:

Уровень	Что можно отследить	Как это сделать
Сеть	Посещаемые сайты, DNS-запросы, сетевые соединения	Transparent Proxy, DPI (глубокий анализ пакетов), межсетевые экраны, снифферы
Файлы	Кто, что, куда копирует	DLP, FSRM, File Integrity Monitoring
Процессы	Что запускается, какие команды выполняются	Sysmon, PowerShell Transcription, EDR-решения
Пользовательская активность	Входы в систему, действия, запросы к ресурсам	Журналы Active Directory, SIEM, EDR
USB-устройства	Подключение устройств, копирование данных	Групповые политики (GPO), контроль устройств в EDR
Почта	Объём, содержимое, получатели	DLP, Exchange Journaling
Клиентские устройства	Наличие антивируса, статус обновлений, наличие root-доступа	EDR, MDM (Intune), SCCM

Что нельзя или сложно отследить?

Активность	Почему сложно	Как частично решить
Чаты в Telegram/WhatsApp	Шифрованный end-to-end трафик, отсутствие доступа к содержимому	Блокировка доменов, фильтрация на уровне сети, политики использования
Локальные копии документов	Не проходят через централизованные системы мониторинга	Шифрование дисков (BitLocker), ограничение копирования, использование DLP
Скрытая работа через VNC/TeamViewer	Возможность обхода корпоративных политик	Запрет программ через AppLocker, мониторинг активности с помощью EDR
Обёртки (containers)	Docker-контейнеры могут запускать вредоносный код в изолированной среде	Мониторинг контейнеров, применение CIS Benchmarks для платформ виртуализации
Шифрованный трафик (TLS)	Содержимое не доступно без расшифровки	Прозрачный прокси с MITM (man-in-the-middle), требует установки доверенного корневого сертификата
Работа вне домена	Пользователь находится вне контроля доменных политик	Использование автономных EDR-агентов, MDM для управления устройствами
Локальное хранение данных	Использование флешек, облачных дисков вне учётной записи	DLP, запрет внешних носителей через GPO, мониторинг облачных загрузок
Root-доступ / jailbreak	Может обходить механизмы защиты, включая EDR	Использование EDR с детектированием руткитов и признаков компрометации ОС

Какие технологии используются для контроля?

Sysmon (System Monitor). Логирует события ядра Windows.
EDR (Endpoint Detection and Response). Мониторинг и защита рабочих станций.
SIEM (Security Information and Event Management). Централизованное логирование и алерты.
DLP (Data Loss Prevention). Предотвращение утечки данных.
File Server Auditing. Логирование действий с файлами.
GPO (Group Policy Objects). Централизованное управление политиками.
AppLocker / Device Guard. Блокировка запуска неподписанных программ.
PowerShell Transcription / Module Logging. Логирование всех команд PowerShell.
Transparent Proxy / DPI. Расшифровка и анализ трафика.
MDM / MAM (Mobile Device Management). Управление устройствами вне офиса.

Но при настройке такого отслеживания нужно уведомить сотрудников о том, что их активность отслеживается. Сбор данных должен быть ограничен и обоснован.

К примеру, можно узнать посещение сайта, запросы к API, факты использования программ, время, которое пользователь провёл на сайте, скачивание файлов, использование сервисов, потому что весь трафик проходит через доменную сеть. Нельзя разве что узнать текст, который отправляется на сайт или в мессенджер - такое не узнать без MITM.

Компания может установить корневой сертификат на устройство, и браузер станет доверять - после чего прокси-сервер сделает «переподпись» SSL-соединения, и всё - администратор видит полностью расшифрованный трафик. Некоторые компани устанавливают EDR с мониторингом экрана - вот он даёт полный доступ к тому, что пишут и читают.

А вот теперь давайте поговорим о другом, более страшном.

Как узнать, не следят ли за вами?

Если вы используете рабочее устройство, подключены к VPN, входите в домен Active Directory, то скорее всего, за вами следят по умолчанию.

Более строгие признаки:

установлен EDR агент - CrowdStrike, SentinelOne, Microsoft Defender ATP;
имеется антивирус с мониторингом экрана - Symantec, Kaspersky Endpoint Security;
присутствует DLP-решение - Forcepoint, McAfee DLP, Digital Guardian;
имеются файлы в системе от имени компании;
имеются расширения в браузере от IT-отдела, например от Kaspersky, Cisco;
используется прозрачный прокси / MITM (HTTPS-сайты показывают сертификат компании);
мониторинг через MDM - Intune, Jamf (для Mac);
системные логи показывают аудит - Event Viewer → Windows Logs → Security.

Проверьте установленное ПО - изучите всё подозрительное.
Проверьте процессы, к примеру, подозрительными будут:
- sentinelagent.exe (CrowdStrike)
- Cytool.exe (Carbon Black)
- wdavdaemon (Microsoft Defender)
- TaniumClient, BigFix, SCCM, JamfAgent
Проверьте сетевой трафик, используйте Wireshark, Fiddler или tcpdump. Если все запросы идут через определённый IP (допустим, корпоративный), и есть высокая активность в фоне, даже когда вы ничего не делаете - значит есть слежка.
Проверьте сертификаты - если сайт открывается без ошибок, но в адресной строке видно, что сертификат принадлежит вашей компании — это MITM-прокси.
Политики безопасности - если в Windows применить gpresult /H report.html, то откроется файл с применёнными групповыми политиками. Там нужны будут политики типа Audit Policy, AppLocker, PowerShell Logging,Device Guard.
Как узнать, что вас прослушивают или шпионят?
- неожиданная активность камеры или микрофона - значит установлен вредоносный софт;
- незнакомые службы запускаются при старте - слежка, EDR, DLP;
- браузер показывает, что SSL-соединение не безопасно - MITM-сертификаты;
- внезапные скриншоты экрана, перезагрузки - мониторинг через EDR;
- USB-устройства блокируются - политика Device Control;
- файлы нельзя сохранить на флешку - DLP-политики ограничивают копирование;
- кто-то знает что вы делали в Chrome - прокси-логирование, EDR с мониторингом браузера.

Шифрование

Шифрование (Encryption) - это процесс преобразования данных в защищённый формат, чтобы только авторизованные пользователи могли их прочитать.

Шифрование бывает:

симметричное - используется один ключ для шифрования и расшифровки;
асимметричное - используются два ключа - публичный и приватный.

Это нужно для защиты данных при передаче.

Шифрование использует безопасные алгоритмы AES-256, ChaCha20-Poly1305.

Хэширование (Hashing) - это одностороннее преобразование данных в уникальную строку фиксированной длины. Не может быть обратным.

К примеру, если мы преобразуем «HELLO» по алгоритмам:

Алгоритм	Результат
MD5	`5d41402abc4b2a76b9719d911017c592`
SHA-1	`a57f5f3a14be99a5ac86b1cb6ea9673b`
SHA-256	`2cf24dba5fb0a30e26e83b2ac5b9e2901b161e5c1fa7425e73043362938b9826`

Хэширование использует безопасные алгоритмы SHA-256, SHA-3, Blake2. Захэшированные данные нельзя расшифровать, только сверить хэш. HMAC (Hash-based Message Authentication Code) - это механизм проверки целостности и подлинности сообщения, использующий общий секретный ключ и хэш-функцию. Применяется в API-ключах, JWT и аутентификации сообщений.

HMAC применяет безопасные алгоритмы HMAC-SHA256, HMAC-SHA512.

Шифрование тесно связано с подписями и подлинностью.

Электронная цифровая подпись (ЭЦП) — это криптографический механизм, позволяющий убедиться в подлинности отправителя, неизменности данных и доказать факт подписания (неотказуемость).

Как это работает?

Создаётся хэш от документа (SHA-256);
Хэш подписывается приватным ключом отправителя;
Получатель проверяет подпись с помощью публичного ключа.

Так и происходит подпись документов, удостоверение программ, работа с SSL/TLS сертификатами, а также блокчейн-транзакции.

Подписи используют безопасные алгоритмы RSA-2048+, ECDSA, Ed25519.

Base64 - это кодирование. Кодирование и шифрование - разные вещи, к примеру, Base64 просто представляет бинарные данные в виде текста, но не защищает их. Base64 легко декодируется, не обеспечивает конфиденциальности, и многие часто ошибочно принимают его за шифрование.

Если нужно скрыть данные от других - применяется шифрование. Если нужно проверить подлинность - HMAC. Если нужно подписать документ - цифровую подпись. А если нужно отправить бинарные данные в виде строки через API - Base64.

Авторизация и аутентификация

В современных информационных системах управление доступом — неотъемлемый элемент архитектуры. Независимо от того, разрабатывается ли веб-приложение, мобильное приложение, корпоративная ERP-система или облачный микросервис, важно строго определять, кто пытается получить доступ к системе (аутентификация) и что ему разрешено делать (авторизация). Эти два процесса, хотя и тесно связаны, решают принципиально разные задачи и реализуются различными подходами, механизмами и протоколами.

Конфузия между аутентификацией и авторизацией — одна из самых распространённых ошибок даже среди опытных разработчиков. Такая путаница ведёт к уязвимостям в системах безопасности, некорректному управлению правами и, как следствие, к серьёзным инцидентам: утечкам данных, несанкционированному доступу, повреждению инфраструктуры.

Данная глава призвана систематизировать знания об этих двух ключевых механизмах, детализировать их внутреннее устройство, рассмотреть архитектурные паттерны, распространённые протоколы и готовые решения, а также дать практические рекомендации по их корректной реализации в различных типах приложений.

1. Аутентификация: «Кто ты?»

Аутентификация — это процесс подтверждения личности пользователя или субъекта, пытающегося получить доступ к системе. Этот этап всегда предшествует авторизации и отвечает на вопрос: «Кто ты?».

В основе аутентификации лежит проверка одного или нескольких факторов подлинности:

Что-то, что вы знаете (например, пароль, PIN-код);
Что-то, что у вас есть (например, аппаратный токен, смартфон с приложением Google Authenticator);
Что-то, что вы являетесь (биометрические данные: отпечаток пальца, лицо, голос).

Сочетание двух и более факторов называется многофакторной аутентификацией (MFA). Она значительно повышает уровень безопасности, поскольку компрометация одного фактора (например, утечка пароля) не приводит к полному доступу злоумышленника.

Виды аутентификации

Парольная аутентификация
Наиболее распространённый, но наименее защищённый метод. Основан на проверке пары логин/пароль. Без дополнительных мер (хэширование с солью, ограничение попыток, MFA) уязвима к брутфорсу, фишингу и утечкам баз данных.
Базовая аутентификация (Basic Authentication)
Реализуется передачей логина и пароля в заголовке HTTP-запроса в закодированном виде (Base64). Не рекомендуется в чистом виде без шифрования TLS, так как данные легко декодируются. Используется в тестовых средах или внутренних API с ограничениями трафика.
Биометрическая аутентификация
Основана на уникальных физиологических или поведенческих характеристиках. Требует надёжного хранения шаблонов и защиты от подмены (например, фото вместо лица). Применяется в мобильных устройствах, системах физического доступа.
Сертификатная аутентификация
Использует X.509-сертификаты для подтверждения подлинности клиента. Применяется в корпоративных и высоконадёжных системах, где требуется строгая идентификация без участия пользователя.
Токен-ориентированная аутентификация
Использует криптографически подписанные токены (например, JWT) для передачи идентификатора пользователя и его атрибутов. Подробно рассматривается в разделе о JWT.
Протокольная аутентификация
Включает такие стандарты, как:
- OAuth 2.0: в первую очередь предназначен для делегирования доступа, но часто используется и для аутентификации (через OpenID Connect).
- OpenID Connect (OIDC): надстройка над OAuth 2.0, специально созданная для аутентификации. Позволяет использовать внешние провайдеры (Google, Microsoft и др.).
- SAML (Security Assertion Markup Language): XML-стандарт для единого входа (SSO), широко применяемый в корпоративных средах.
- Kerberos / NTLM: протоколы, используемые в Windows-доменах для аутентификации в закрытых сетях.

Готовые решения

Для сокращения времени разработки и повышения уровня безопасности рекомендуется использовать проверенные платформы:

Auth0 — облачный Identity-as-a-Service (IDaaS) с поддержкой множества протоколов.
Firebase Authentication — простая интеграция для веб- и мобильных приложений с поддержкой социальных провайдеров.
Keycloak — open-source решение с поддержкой OAuth 2.0, OIDC, SAML, ролевой модели и расширенной настройки.
Azure Active Directory (Entra ID) — корпоративное решение Microsoft, интегрируемое с Office 365, Windows и Azure-сервисами.
Okta — коммерческая платформа с мощным UI, жизненным циклом пользователей и MFA.

2. Авторизация: «Что тебе разрешено?»

Если аутентификация отвечает на вопрос «Кто ты?», то авторизация отвечает на «Что тебе разрешено?». Это процесс проверки прав доступа субъекта (пользователя, сервиса, устройства) к объекту (файлу, API-эндпоинту, функции).

Авторизация выполняется после успешной аутентификации. Без подтверждённой личности проверка прав не имеет смысла.

Модели управления доступом

Существует несколько ключевых моделей авторизации, каждая из которых подходит для определённого класса систем:

RBAC (Role-Based Access Control)
Доступ определяется через роли. Пользователь назначается одной или несколькими ролями, а каждой роли присваивается набор разрешений (permissions).
Пример: Роль admin может удалять пользователей, роль user — только просматривать профиль.
ABAC (Attribute-Based Access Control)
Доступ определяется на основе атрибутов: пользователя (отдел, должность), ресурса (категория, владелец), среды (время суток, геолокация, IP-адрес).
Пример: Пользователь из отдела «Финансы» имеет доступ к документу «Бюджет», если время запроса — в рабочие часы и IP принадлежит корпоративной сети.
PBAC (Policy-Based Access Control)
Более обобщённый подход, где доступ управляется политиками — логическими правилами, которые могут включать условия из ABAC, временные ограничения, контекст устройства и т.п.
Пример: «Доступ к административной панели разрешён только с доверенного устройства и только при включённой 2FA».
ACL (Access Control List)
Классический подход: у каждого ресурса есть список, где указано, какие субъекты имеют к нему доступ и с какими правами. Гибок, но трудно масштабируем при большом числе пользователей и ресурсов.

Механизмы авторизации

Списки разрешений (Permissions)
Минимальная единица контроля доступа. Например: read:documents, write:users, delete:posts. Комбинируются в роли или политики.
Делегирование доступа
Пользователь может временно передавать свои права другому субъекту (например, через OAuth). Это особенно важно в SaaS-системах и интеграциях.
Сессии и токены
После аутентификации система должна каким-то образом помнить, что пользователь уже прошёл проверку. Это реализуется через:
- Сессии (сервер хранит состояние в памяти или БД, клиент получает session ID в cookie);
- Токены (клиент хранит состояние, сервер проверяет подпись и содержимое токена — stateless подход).

3. JSON Web Tokens (JWT): архитектура и применение

JSON Web Token (JWT) — это открытый стандарт (RFC 7519), предназначенный для компактной и безопасной передачи утверждений (claims) между двумя сторонами. JWT часто используется как механизм аутентификации и авторизации в stateless-приложениях, особенно в RESTful API и микросервисных архитектурах.

Структура JWT

JWT состоит из трёх частей, разделённых точками (.):

Header — метаданные токена. Содержит тип токена ("typ": "JWT") и алгоритм подписи ("alg"). Пример:
```
{
  "alg": "HS256",
  "typ": "JWT"
}
```
Payload — тело токена. Содержит утверждения (claims). Существуют три типа claims:
- Зарезервированные (iss, exp, sub, aud и др.) — стандартизированы, но не обязательны.
- Публичные — согласованные между сторонами (например, role, department).
- Приватные — специфичные для приложения (например, user_id, is_premium).
Пример payload:
```
{
  "sub": "1234567890",
  "name": "Тимур Тагиров",
  "role": "admin",
  "exp": 1730000000
}
```
Signature — криптографическая подпись, гарантирующая целостность токена. Формируется путём:
- Кодирования header и payload в Base64Url;
- Конкатенации их через точку;
- Подписи полученной строки с использованием секретного ключа (HMAC) или закрытого ключа (RSA/ECDSA).
Пример подписи (для HMAC):
```
HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)
```

Результирующий токен выглядит так:
xxxxx.yyyyy.zzzzz

Применение JWT

Аутентификация
После успешного входа пользователь получает JWT. При последующих запросах он передаёт токен (обычно в заголовке Authorization: Bearer <token>). Сервер проверяет подпись и срок действия, после чего считает запрос аутентифицированным.
Авторизация
Роли и разрешения кодируются в payload. Например, наличие "role": "admin" позволяет контроллеру разрешить доступ к защищённому эндпоинту.
Единый вход (SSO)
JWT может использоваться как токен обмена между сервисами в рамках единой экосистемы. Например, сервис аутентификации генерирует токен, который принимают все микросервисы.

Ограничения и риски

JWT не отменяется
Поскольку JWT stateless, его нельзя инвалидировать до истечения срока действия (exp). Решения:
- Использовать короткий срок жизни (например, 15 минут) и пару access/refresh tokens;
- Вести чёрный список недействительных токенов (например, в Redis).
Хранение на клиенте
Хранение JWT в localStorage подвержено атакам XSS; в HttpOnly cookie — атакам CSRF. Оптимальный выбор зависит от архитектуры и уровня угроз.
Подделка токена
Если сервер использует слабый или утечку секретного ключа, злоумышленник может сгенерировать валидный JWT. Требуется тщательное управление ключами.

4. Валидация входных данных и управление доверием

Аутентификация и авторизация не защищены, если входные данные не проходят строгую валидацию. Уязвимости типа insecure direct object reference (IDOR) или injection часто возникают из-за отсутствия проверки входных параметров.

Белый и чёрный списки

Белый список (allowlist) — явное разрешение только известных, ожидаемых значений.
Пример: разрешить выбор роли только из ["user", "moderator", "admin"].
Чёрный список (blocklist) — попытка запретить опасные значения. Не рекомендуется, так как невозможно перечислить все возможные векторы атаки.

Белый список — единственный надёжный подход в критичных местах (ролях, путях файлов, идентификаторах).

Библиотеки валидации

Для обеспечения типобезопасности и валидации структуры данных используются специализированные библиотеки:

Python: Marshmallow — декларативная валидация и сериализация объектов.
Node.js: Joi (ныне @hapi/joi) или Zod — строгая схема валидации с поддержкой кастомных правил.
C#: встроенные механизмы Data Annotations ([Required], [StringLength]) и библиотеки вроде FluentValidation.
Java: Bean Validation (@NotNull, @Pattern) + Hibernate Validator.

Пример на Python (Marshmallow):

from marshmallow import Schema, fields

class LoginSchema(Schema):
    username = fields.Str(required=True, validate=validate.Length(min=3, max=32))
    password = fields.Str(required=True, validate=validate.Length(min=8))

Такой подход предотвращает передачу неожиданных или вредоносных данных на уровень аутентификации.

5. Управление сессиями и stateful-подход

Хотя JWT популярен, сессионная аутентификация остаётся актуальной, особенно в монолитных веб-приложениях.

Как работает сессия

Пользователь отправляет логин и пароль.
Сервер проверяет учётные данные.
При успехе создаётся объект сессии на сервере (в памяти, Redis, БД).
Клиенту возвращается session ID (обычно в Set-Cookie).
При последующих запросах браузер автоматически отправляет cookie с session ID.
Сервер находит сессию по ID и проверяет её валидность.

Преимущества сессий

Возможность мгновенной отмены (удаление из хранилища).
Отсутствие передачи чувствительных данных клиенту.
Встроенная защита от XSS при использовании HttpOnly cookie.

Недостатки

Требует stateful-архитектуры (сложнее масштабировать).
Неудобно в мобильных и SPA-приложениях без дополнительной обвязки.

6. Готовые фреймворки: Identity, Keycloak, Auth0

ASP.NET Core Identity

Встроенная система управления пользователями в .NET. Включает:

CRUD-операции над пользователями и ролями.
Хранение в таблицах: AspNetUsers, AspNetRoles, AspNetUserRoles.
Поддержку внешних провайдеров (Google, Facebook).
Встроенную двухфакторную аутентификацию (2FA) через TOTP или SMS.

Пример включения 2FA:

// Включение 2FA
await _userManager.SetTwoFactorEnabledAsync(user, true);

// Генерация секретного ключа для Google Authenticator
var key = await _userManager.GetAuthenticatorKeyAsync(user);
if (string.IsNullOrEmpty(key))
{
    await _userManager.ResetAuthenticatorKeyAsync(user);
    key = await _userManager.GetAuthenticatorKeyAsync(user);
}

Проверка TOTP-кода:

var isValid = await _userManager.VerifyTwoFactorTokenAsync(
    user, _userManager.Options.Tokens.AuthenticatorTokenProvider, code);

Keycloak

Open-source Identity и Access Management (IAM) сервер. Поддерживает:

OAuth 2.0, OpenID Connect, SAML.
RBAC, fine-grained permissions.
Адаптеры для Java, JavaScript, .NET, Python.
UI для управления пользователями и ролями.

Auth0 и Okta

Облачные решения с минимальной настройкой. Подходят для стартапов и SaaS-продуктов. Предоставляют:

Готовые экраны входа/регистрации.
Аналитику аутентификации.
Поддержку социальных провайдеров.
Управление MFA, блокировку брутфорса, anomaly detection.

7. Единый вход (Single Sign-On, SSO)

Single Sign-On (SSO) — архитектурный паттерн, позволяющий пользователю аутентифицироваться один раз и получить доступ к множеству взаимодействующих систем без повторного ввода учётных данных.

Принцип работы

Пользователь пытается получить доступ к приложению A.
Приложение A перенаправляет его на Identity Provider (IdP).
Если пользователь не аутентифицирован в IdP — ему предлагается войти.
После успешной аутентификации IdP генерирует утверждение (assertion) и перенаправляет пользователя обратно в приложение A с этим утверждением.
Приложение A проверяет подлинность утверждения и создаёт локальную сессию.

Стандарты SSO

SAML (Security Assertion Markup Language)
XML-ориентированный стандарт, доминирующий в корпоративном секторе (особенно в интеграциях с Microsoft, SAP, Salesforce). Обеспечивает надёжную передачу атрибутов и поддержку федеративной идентификации.
OpenID Connect (OIDC)
Современный, JSON/REST-ориентированный стандарт на базе OAuth 2.0. Широко используется в облачных и веб-приложениях. Проще в реализации, чем SAML, и лучше подходит для SPA и мобильных клиентов.
OAuth 2.0 как основа
Хотя OAuth 2.0 изначально не предназначен для аутентификации, в связке с OIDC он становится полноценным SSO-решением. Провайдеры (Google, Microsoft, GitHub) предоставляют OIDC-эндпоинты (/.well-known/openid-configuration).

Преимущества SSO

Улучшение UX: пользователь входит один раз.
Централизованный контроль: администратор управляет доступом в одном месте.
Снижение рисков: меньше паролей → меньше утечек.
Упрощённый аудит и логирование.

Риски

Единая точка отказа: компрометация IdP даёт доступ ко всем системам.
Сложность отмены доступа: требуется своевременная синхронизация статуса учётной записи.

8. Интеграция аутентификации и авторизации в разные типы приложений

8.1. Веб-приложения

Традиционные (server-rendered)
Используют сессионную аутентификацию с HttpOnly cookie. CSRF-токены обязательны. Авторизация реализуется через middleware (например, [Authorize] в ASP.NET, @login_required в Django).
SPA (React, Angular, Vue)
Чаще используют токен-ориентированный подход (JWT). Токен хранится в памяти (не в localStorage) для защиты от XSS. Авторизация на фронтенде — декоративна; окончательная проверка всегда на бэкенде.
API-first архитектура
Все эндпоинты защищаются через заголовок Authorization: Bearer <token>. Используются кастомные middleware или библиотеки (express-jwt, Flask-JWT-Extended, Microsoft.AspNetCore.Authentication.JwtBearer).

8.2. Десктопные приложения

Native-приложения (WPF, WinForms, Electron)
Аутентификация часто реализуется через браузерную перенаправляющую модель (OAuth 2.0 Authorization Code + PKCE). Это безопаснее хранения логина/пароля в приложении.
После получения токена он сохраняется в защищённом хранилище ОС: Windows Credential Vault, Keychain (macOS), libsecret (Linux).
Автономные системы
В отсутствие сети может применяться локальная аутентификация (например, хэши паролей в зашифрованном файле), но с ограничениями: нет централизованного управления, нет SSO.

8.3. Мобильные приложения

OAuth 2.0 + PKCE — рекомендуемый стандарт (RFC 7636). Предотвращает перехват authorization code.
Biometric Unlock — после первоначального входа пользователь может разблокировать приложение отпечатком, но JWT/refresh token остаются в защищённом хранилище (Android Keystore, iOS Secure Enclave).
Refresh Tokens — критически важны из-за долгой сессии. Должны быть привязаны к устройству и иметь механизм отмены.

9. Практические рекомендации по проектированию системы доступа

Разделяйте аутентификацию и авторизацию
Не смешивайте проверку личности и проверку прав. Используйте отдельные компоненты (IdP и Policy Engine).
Минимизируйте привилегии (Principle of Least Privilege)
Пользователь должен получать только те права, которые необходимы для выполнения задачи.
Никогда не храните пароли в открытом виде
Используйте адаптивные хэш-функции: Argon2, scrypt, bcrypt. Не используйте MD5 или SHA1.
Используйте HTTPS повсеместно
Без TLS любой механизм аутентификации уязвим к перехвату.
Внедряйте многофакторную аутентификацию (MFA)
Особенно для администраторов и привилегированных учётных записей.
Ведите аудит действий
Логируйте входы, выходы, изменения прав, неудачные попытки входа. Это необходимо для расследования инцидентов.
Избегайте самописных криптографических решений
Используйте проверенные библиотеки и протоколы. «Security through obscurity» не работает.
Тестируйте на уязвимости
Регулярно проводите аудиты: проверяйте на IDOR, broken access control (OWASP Top 10), утечки токенов.

Устаревшие подходы

В эволюции информационных технологий многие методы, протоколы и практики, ранее считавшиеся стандартными, оказались уязвимыми к современным атакам. Их применение сегодня — не просто технический анахронизм, а прямая угроза безопасности системы. Ниже перечислены и проанализированы категорически устаревшие или опасные подходы, которые не должны использоваться в новых проектах и подлежат замене в существующих.

1. Устаревшие криптографические хэш-функции

MD5

Алгоритм MD5, разработанный в 1992 году, был изначально ориентирован на контроль целостности, а не на безопасное хранение паролей. Однако долгое время он применялся для хэширования учётных данных.
Проблемы:

Коллизии могут быть найдены за считанные секунды на обычном оборудовании.
Полностью скомпрометирован: существуют готовые rainbow tables и сервисы обратного поиска.
Не обладает устойчивостью к атакам по времени и предвычислению.

Статус: запрещён для любых задач, связанных с безопасностью (RFC 6151).

SHA-1

Хотя SHA-1 значительно надёжнее MD5, к 2020-м годам были продемонстрированы практические атаки нахождения коллизий (проект SHAttered, 2017).
Проблемы:

Сниженная стойкость к коллизиям делает его непригодным для цифровых подписей и сертификатов.
Уже не поддерживается ведущими браузерами и ОС как стандарт для TLS.

Статус: устарел, не рекомендуется даже для целостности; заменён на SHA-2 (SHA-256, SHA-384) и SHA-3.

Важно: ни MD5, ни SHA-1 никогда не предназначались для хранения паролей. Их использование для этой цели — грубейшая ошибка.

2. Небезопасные алгоритмы симметричного шифрования

DES (Data Encryption Standard)

Разработан в 1970-х, использует 56-битный ключ.
Проблемы:

Ключ слишком короткий: перебор возможен за часы на коммерческом оборудовании.
Уязвим к атакам на основе дифференциального и линейного криптоанализа.

Статус: объявлен небезопасным NIST в 1999 году.

3DES (Triple DES)

Являлся временной заменой DES: применяет DES трижды с разными ключами.
Проблемы:

Эффективная длина ключа ниже заявленной из-за слабостей конструкции.
Медленный и неэффективный по сравнению с современными алгоритмами.
Уязвим к атаке «встреча посередине» (meet-in-the-middle).

Статус: запрещён для новых применений (NIST SP 800-131A, 2023); поддержка прекращена в TLS 1.3.

ECB (Electronic Codebook) — режим шифрования

Часто ошибочно называют «EC4» (нет такого стандарта; вероятно, имеется в виду ECB).
Проблемы:

Одинаковые блоки открытого текста шифруются в одинаковые блоки шифротекста.
Нет диффузии: структура данных сохраняется (например, изображения остаются различимыми).
Не обеспечивает семантическую безопасность.

Статус: непригоден для шифрования данных с повторяющимися структурами. Допустим только для очень специфичных случаев (например, шифрование ключей по стандарту ANSI X9.52), но даже там предпочтительны другие режимы.

Современная альтернатива: AES (Advanced Encryption Standard) в режимах GCM (аутентифицированное шифрование) или CBC с корректной инициализацией (IV).

3. Хранение паролей без соли (salt)

Хэширование паролей без соли — фатальная ошибка.
Проблемы:

Позволяет применять rainbow tables — предвычисленные таблицы хэшей для миллионов распространённых паролей.
Одинаковые пароли разных пользователей дают одинаковые хэши, что упрощает массовую компрометацию.
Не защищает от атак по словарю даже при использовании «сильного» алгоритма (например, SHA-256 без соли всё ещё уязвим).

Требование: каждый пароль должен хэшироваться с уникальной, криптографически случайной солью, длиной не менее 16 байт. Соль хранится в открытом виде рядом с хэшем.

4. Хранение секретов в открытом виде

Plain text (открытый текст)

Хранение паролей, ключей API, токенов или других секретов в виде простого текста — недопустимо.
Примеры уязвимостей:

Пароли в исходном коде (hardcoded credentials);
Логирование паролей или токенов;
Конфигурационные файлы без шифрования;
Передача учётных данных в GET-параметрах URL.

Последствия: немедленный компромет при утечке логов, репозиториев, дампов памяти.

Решение: использовать сейфы секретов (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), переменные окружения (с осторожностью), или зашифрованные конфиги с контролем доступа.

5. Самопальные криптографические схемы

Разработка «собственного» алгоритма хэширования, шифрования или генерации ключей — один из самых опасных анти-паттернов.
Причины:

Криптография — область с чрезвычайно высоким порогом экспертизы.
Даже незначительная ошибка в конструкции делает систему полностью уязвимой.
Отсутствие peer review и долгосрочного анализа.

Принцип: никогда не изобретайте криптографию. Используйте только стандартизированные, широко проверенные алгоритмы и библиотеки (OpenSSL, libsodium, .NET Cryptography, Bouncy Castle).

6. Использование устаревших протоколов и механизмов

HTTP Basic Auth без TLS — передача логина/пароля в Base64 (не шифрование!);
Digest Access Authentication — устаревший, уязвимый к атакам на перехват сессии;
TLS 1.0 / 1.1 — содержат критические уязвимости (POODLE, BEAST); запрещены PCI DSS с 2018 года;
SSLv3 и ниже — полностью скомпрометированы.

Уровни доверия и SSL/TLS

Уровни доверия:

Уровень	Применение	Пример
Высокий	Банки, государственные системы, критически важные инфраструктуры	Двухфакторная аутентификация (2FA), использование HSM-ключей для защиты секретов
Средний	Корпоративные порталы, внутренние CRM и ERP-системы	Комбинация пароля и одноразового кода по SMS или из приложения
Низкий	Блоги, форумы, публичные ресурсы с минимальными требованиями к безопасности	Аутентификация по простому паролю без дополнительных факторов

SSL / TLS – процесс шифрования трафика между клиентом и сервером. Браузер при установлении показывает значок замка и https://. Для проверки используется сертификат:

DV (Domain Validation) – базовый (проверка домена);
OV (Organization Validation) – проверка компании;
EV (Extended Validation) – максимальная проверка.

Методы проверки подлинности

Основные методы

Метод	Как работает?	Плюсы/Минусы
Логин и пароль	Проверка учётных данных на сервере по базе данных (хешированных паролей)	Плюсы: Простота реализации и использования. Минусы: Уязвимость к подбору, фишингу, необходимость безопасного хранения.
OAuth 2.0	Пользователь аутентифицируется через стороннего провайдера (Google, Facebook и др.), приложение получает токен доступа	Плюсы: Удобство для пользователя, снижение нагрузки на разработчика. Минусы: Зависимость от внешнего провайдера, передача части контроля.
JWT (JSON Web Tokens)	Токен в формате JSON, подписанный сервером; содержит данные (например, роль, срок действия); хранится у клиента	Плюсы: Отсутствие состояния на сервере, высокая масштабируемость. Минусы: Невозможность отзыва до истечения срока (без дополнительных механизмов).
Биометрия	Идентификация по уникальным биологическим признакам: отпечаток пальца, распознавание лица (Face ID)	Плюсы: Высокая степень защиты от несанкционированного доступа. Минусы: Требует специализированного оборудования, сложности с восстановлением при изменении данных.

JWT и сессии – сравнение

Критерий	JWT	Сессии
Место хранения состояния	На стороне клиента (в токене)	На стороне сервера (в session store, например Redis)
Масштабируемость	Высокая — не требует общего хранилища сессий	Ниже — требует централизованного хранилища (например, Redis) для работы в кластере
Безопасность	Зависит от стойкости алгоритма подписи и секрета	Зависит от защиты session ID и надёжности серверного хранилища

Верификация подлинности включает в себя и проверку домена. К примеру, почтового домена при отправлении рассылок, которая нобходима для правильного отображения имени отправителя в рассылке, а также для исключения несанкционированных рассылок.

Электронная почта остаётся одной из самых уязвимых и активно эксплуатируемых точек входа в информационные системы. Фишинг, спуфинг, рассылка вредоносного ПО и бизнес-электронное мошенничество (BEC) часто основаны на подделке адреса отправителя. Для противодействия этим угрозам были разработаны стандартизированные механизмы проверки подлинности писем на уровне DNS и криптографии: SPF и DKIM. Они являются фундаментальными компонентами современной инфраструктуры доверия в email-коммуникациях и обязательны к внедрению для любого домена, отправляющего почту.

1. Sender Policy Framework (SPF)

Назначение

SPF — это механизм, позволяющий владельцу домена публиковать список авторизованных почтовых серверов, с которых разрешено отправлять письма от имени этого домена.

Принцип работы

Администратор домена публикует в DNS TXT-запись вида:
```
v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 include:_spf.google.com -all
```
Эта запись означает: «Письма от @example.com могут быть отправлены только с IP-адресов 192.0.2.0/24, 198.51.100.123 или серверов Google Workspace».
При получении письма принимающий MTA (Mail Transfer Agent):
- извлекает домен из envelope sender (обычно поле Return-Path);
- запрашивает SPF-запись для этого домена в DNS;
- сравнивает IP-адрес отправившего сервера с разрешёнными в записи.
Результат проверки может быть:
- pass — адрес авторизован;
- fail (-all) — явный запрет;
- softfail (~all) — временный отказ (для отладки);
- neutral (?all) — без указания политики.

Ограничения SPF

Не работает при пересылке: если письмо пересылается через третью систему (например, корпоративный фильтр), envelope sender может измениться, и проверка провалится.
Не проверяет поле From:, отображаемое пользователю. Это критически важно: злоумышленник может подделать From: ceo@yourcompany.com, даже если envelope sender — другой домен. Поэтому SPF должен использоваться вместе с DMARC, который связывает проверку с видимым адресом отправителя.

2. DomainKeys Identified Mail (DKIM)

Назначение

DKIM — это криптографический механизм, позволяющий подписывать письма цифровой подписью и подтверждать, что:

письмо действительно отправлено с авторизованного сервера домена;
содержимое письма (включая заголовки) не было изменено в пути.

Принцип работы

Отправляющий сервер:
- выбирает набор заголовков для подписи (например, From, Subject, Date);
- генерирует хэш от тела письма и выбранных заголовков;
- подписывает хэш закрытым ключом;
- добавляет в письмо заголовок DKIM-Signature, содержащий:
  - домен (d=);
  - селектор ключа (s=);
  - алгоритм подписи;
  - подпись.
Принимающий сервер:
- извлекает из DKIM-Signature домен и селектор;
- запрашивает в DNS TXT-запись по имени {selector}._domainkey.{domain};
- получает открытый ключ;
- проверяет подпись с помощью этого ключа.

Пример DNS-записи DKIM:

google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Преимущества DKIM

Целостность: любое изменение тела или подписанных заголовков делает подпись недействительной.
Независимость от маршрута: работает при пересылке, так как подпись не зависит от envelope sender.
Доверие: крупные почтовые провайдеры (Gmail, Outlook) повышают репутацию доменов с корректной DKIM-подписью.

Важные нюансы

Подпись не шифрует письмо — она только гарантирует его неизменность и источник.
Ключи должны регулярно ротироваться (рекомендуется раз в 3–6 месяцев).
Не проверяет, имел ли отправитель право отправлять от имени домена — только то, что письмо прошло через систему, владеющую закрытым ключом.

3. SPF и DKIM в совокупности: необходимость DMARC

Ни SPF, ни DKIM по отдельности не защищают пользователя от подделки отображаемого адреса отправителя (From:). Для объединения политик и принятия решений на основе результатов SPF/DKIM используется DMARC (Domain-based Message Authentication, Reporting & Conformance).

DMARC позволяет владельцу домена:

указать, какие механизмы (SPF, DKIM или оба) требуются для прохождения аутентификации;
задать политику обработки писем, не прошедших проверку (none, quarantine, reject);
получать агрегированные и детальные отчёты от почтовых провайдеров.

Пример DMARC-записи:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Только при наличии всех трёх компонентов — SPF + DKIM + DMARC — достигается эффективная защита от спуфинга и фишинга.

4. Практические рекомендации

Всегда публикуйте SPF-запись для любого домена, с которого отправляется почта (включая сервисы рассылки, CRM, уведомления).
Настройте DKIM для всех отправляющих систем (включая сторонние — SendGrid, Mailchimp и др.).
Имплементируйте DMARC сначала в режиме p=none для сбора отчётов, затем переходите на quarantine и reject.
Не превышайте 10 DNS-запросов в SPF-записи (ограничение RFC 7208).
Проверяйте конфигурацию с помощью инструментов:
- dig TXT example.com
- MXToolbox, Google Admin Toolbox, dmarcian.

Кибербезопасность

Вирусы и вредоносные программы

Вредоносное программное обеспечение (malware — от англ. malicious software) представляет собой класс программ, разработанных с целью нанесения ущерба пользователям, устройствам или информационным системам. В отличие от легитимного ПО, вредоносные программы не несут прямой функциональной ценности для пользователя и зачастую скрываются под видом полезных или безобидных компонентов. Их цель — компрометация конфиденциальности, целостности и доступности данных, вычислительных ресурсов или сетевой инфраструктуры.

Исторически первым проявлением вредоносного ПО считается программа Creeper, появившаяся в 1971 году в сети ARPANET. Она не имела деструктивных функций, но демонстрировала возможность автономного перемещения между узлами — ключевой признак, лежащий в основе большинства современных угроз. С тех пор вредоносное ПО эволюционировало от простых экспериментальных образцов до сложных, модульных и целенаправленных систем, способных обходить многоуровневые механизмы защиты.

Данная глава посвящена классификации, функциональным особенностям и методам реализации различных типов вредоносного ПО, а также специфике их поведения в разных операционных системах и средах. Особое внимание уделено механизмам сокрытия, перехвата системных вызовов и маскировки под легитимные компоненты операционной системы.

1. Вирусы: определение и классификация

Под термином «компьютерный вирус» в классическом понимании подразумевается саморазмножающаяся программа, внедряющая свой код в другие исполняемые файлы или системные структуры с целью дальнейшего распространения. Вирус не способен к автономному запуску — он требует активации через запуск заражённого файла или выполнение определённого условия.

Основные признаки вирусов:

Самокопирование: внедрение копии кода в другие объекты.
Зависимость от носителя: требует запуска хост-программы.
Условность действия: часто содержит логику активации по времени, событию или внешнему триггеру.

Современное вредоносное ПО редко ограничивается чисто вирусной моделью. Часто используется гибридный подход: вирус комбинируется с червём, трояном или руткитом для расширения функциональности.

Виды вирусов

Файловые вирусы
Инфицируют исполняемые файлы (обычно .exe, .dll, .com). При запуске заражённого файла срабатывает вирусный код, после чего он может заражать другие файлы в системе. Некоторые используют метод перезаписи кода, другие — добавление кода в конец или начало секции, третьи — инъекцию через ресурсы.
Загрузочные вирусы (Boot-sector viruses)
Поражают загрузочный сектор диска (MBR или VBR). Активируются до полной загрузки операционной системы, что делает их особенно труднообнаружимыми. Современные ОС с UEFI Secure Boot значительно ограничили распространение таких угроз, но они не исчезли полностью.
Макровирусы
Распространяются через макросы в документах (Microsoft Word, Excel, PDF с JavaScript). Активируются при открытии документа и выполнении макроса (часто с запросом разрешения от пользователя, который может быть обманут социальной инженерией).
Полиморфные и метаморфные вирусы
Полиморфные вирусы шифруют свой код и используют переменный ключ расшифровки, что затрудняет сигнатурное обнаружение. Метаморфные вирусы не просто шифруются — они изменяют свою структуру на уровне инструкций, сохраняя логику выполнения. Это делает их крайне трудными для анализа статическими методами.
Резидентные и нерезидентные вирусы
Резидентные вирусы загружаются в память и остаются активными в течение всего сеанса работы, перехватывая системные вызовы для заражения файлов «на лету». Нерезидентные активны только в момент запуска хоста и не остаются в памяти после завершения.

2. Фишинг: социальная инженерия как вектор атаки

Фишинг (от англ. phishing) не является вирусом в техническом смысле, но представляет собой ключевой метод доставки вредоносного ПО и кражи учетных данных. Фишинговые атаки основаны на манипуляции восприятием пользователя: жертве предлагается перейти по ссылке, открыть вложение или ввести данные на поддельном сайте, имитирующем легитимный сервис (например, банк, электронная почта, облачное хранилище).

Современные фишинговые кампании часто включают:

Использование доменов, визуально похожих на оригинальные (typosquatting).
Генерацию поддельных SSL-сертификатов (через Let's Encrypt и аналоги).
Встраивание вредоносного кода в HTML-вложения или скрипты.
Эмуляцию интерфейса двухфакторной аутентификации для перехвата временных кодов.

Фишинг остаётся наиболее эффективным вектором начальной компрометации, поскольку обходит технические меры защиты, воздействуя непосредственно на человека — наименее защищённый элемент системы.

3. Особенности вредоносного ПО в различных операционных системах

Windows

Windows остаётся основной мишенью для разработчиков вредоносного ПО по нескольким причинам:

Высокая доля рынка настольных систем.
Богатая экосистема легитимных приложений, которые можно имитировать.
Сложная, но хорошо изученная архитектура API, позволяющая глубокую интеграцию.

Вредоносные программы под Windows активно используют:

COM/ActiveX для автоматизации и выполнения кода в контексте браузера.
Реестр Windows для обеспечения автозагрузки.
Windows Script Host (WSH) для выполнения .vbs, .js скриптов без компиляции.
Scheduled Tasks для планирования периодических действий.

Особое внимание уделяется маскировке под системные процессы, что рассматривается далее.

Linux

Хотя Linux традиционно считается более защищённой системой, вредоносное ПО для неё существует и развивается, особенно в контексте серверных и встраиваемых устройств.

Особенности:

Отсутствие единого GUI снижает эффективность фишинга, но не исключает его полностью.
Модель прав доступа (разделение root/пользователь) усложняет системную компрометацию, но не предотвращает пользовательские атаки.
Вредоносное ПО часто распространяется через:
- Скомпрометированные репозитории или сторонние пакеты.
- Эксплуатацию уязвимостей в веб-сервисах (например, в CMS, SSH-брут).
- Ботнеты на основе скомпрометированных IoT-устройств (Mirai и его производные).

Linux-вирусы редко используют саморазмножение в классическом смысле, но активно применяют:

Подмену бинарных файлов (/bin, /usr/bin).
Загрузку через cron или systemd юниты.
Инъекцию в процессы через LD_PRELOAD.

Мобильные устройства (Android / iOS)

Android — наиболее уязвимая платформа из-за открытости экосистемы и возможности установки приложений из сторонних источников (APK). Распространённые векторы:

Троянские приложения в сторонних магазинах.
Злоупотребление разрешениями (например, BIND_ACCESSIBILITY_SERVICE для автоматизации).
Скрытые майнеры и рекламные SDK с вредоносным поведением.

iOS в силу своей sandbox-архитектуры и строгой верификации App Store значительно менее подвержена классическим вирусам. Однако возможны:

Атаки через enterprise-сертификаты.
Эксплуатация zero-day уязвимостей (например, в WebKit).
Фишинг через iMessage или Safari.

4. Руткиты и перехват системных функций

Руткит (rootkit) — это класс вредоносного ПО, основная цель которого состоит не в причинении прямого вреда, а в обеспечении скрытого, устойчивого присутствия в системе. Термин происходит от unix-терминов root (учётная запись с максимальными привилегиями) и kit (набор инструментов). Современные руткиты не ограничиваются Unix-подобными системами и широко распространены в Windows-среде.

Руткиты делятся на два основных типа по уровню внедрения:

4.1. User-Mode руткиты

Работают в контексте пользовательских процессов и не требуют привилегий ядра. Их основной механизм — перехват вызовов API. Это достигается следующими способами:

Подмена импортируемых функций в IAT (Import Address Table)
При загрузке исполняемого файла ОС заполняет таблицу адресов внешних функций из DLL. Руткит может изменить указатели в IAT, направив вызовы на собственные реализации («хуки»).
Inline-хукинг
Непосредственная модификация кода целевой функции в памяти: первые байты заменяются на инструкцию перехода (JMP) к вредоносной подпрограмме. После выполнения логики перехвата управление может быть передано оригинальной функции.
DLL-инъекция
Принудительная загрузка вредоносной библиотеки в адресное пространство легитимного процесса. Это позволяет исполнять код в контексте доверенного приложения (например, explorer.exe или svchost.exe).

Часто используемые для перехвата системные DLL в Windows:

kernel32.dll — базовые функции работы с процессами, потоками, памятью, файлами.
ntdll.dll — низкоуровневые нативные вызовы ядра Windows NT (Nt* функции).
user32.dll — управление окнами, вводом с клавиатуры и мыши.
advapi32.dll — безопасность, реестр, службы.
ws2_32.dll — сетевые сокеты (Winsock).
urlmon.dll — загрузка URL, часто используется для C2-коммуникации.
netapi32.dll — функции сетевого администрирования (например, для распространения по локальной сети).

Кейлоггеры — частный случай User-Mode руткита. Они перехватывают нажатия клавиш через GetAsyncKeyState, SetWindowsHookEx или прямой доступ к драйверам HID. Современные реализации избегают прямого логгирования, отправляя данные в шифрованном виде на удалённый сервер.

4.2. Kernel-Mode руткиты

Работают на уровне ядра ОС и обладают полным контролем над системой. Для их загрузки требуется:

Подписанный драйвер (в современных версиях Windows с включённой Secure Boot и DSE).
Эксплуатация уязвимости в ядре (например, через уязвимый легитимный драйвер).

Kernel-Mode руткиты могут:

Скрывать процессы, файлы, сетевые соединения, драйверы.
Подменять системные вызовы через SSDT (System Service Descriptor Table) хуки (в x86) или IRP (I/O Request Packet) перехват.
Модифицировать структуры ядра, такие как EPROCESS, чтобы исключить процесс из списка задач.

Поскольку такие руткиты работают на том же уровне, что и антивирусные решения, их обнаружение требует специализированных средств (например, гипервизоров безопасности вроде Hyper-V-based Virtualization-Based Security в Windows 10/11).

5. Маскировка под системные процессы и службы

Вредоносное ПО часто маскируется под легитимные системные компоненты Windows. Это позволяет:

Избежать подозрений пользователя.
Обойти простые правила детекции по имени процесса.
Сохранить устойчивость при перезагрузке (через автозагрузку служб).

Распространённые цели маскировки:

Процесс / Файл	Назначение	Как используется злоумышленниками
`svchost.exe`	Хост для системных служб	Запуск вредоносной службы под этим именем; подмена реального бинарника
`lsass.exe`	Управление аутентификацией	Подмена для кражи хэшей NTLM (Pass-the-Hash атаки)
`services.exe`	Диспетчер служб	Создание фальшивой копии для управления вредоносными службами
`smss.exe`	Сессионный менеджер	Редко, но используется в загрузочных руткитах
`conhost.exe`	Хост консоли	Инъекция для скрытого запуска командной строки
`dwm.exe`	Диспетчер окон рабочего стола	Используется как «тихий» контейнер для вредоносного кода
`RuntimeBroker.exe`	Управление разрешениями UWP	Маскировка под UWP-процесс для обхода песочницы

Методы подмены:

Размещение поддельного исполняемого файла в нестандартной директории с тем же именем (например, C:\Windows\Temp\svchost.exe).
Использование доверенной цифровой подписи, украденной в результате компрометации разработчика.
DLL-подмена: размещение вредоносной DLL рядом с легитимным EXE, который загружает её при запуске (DLL Search Order Hijacking).

Важно: легитимные системные файлы Windows всегда находятся в строго определённых каталогах (%SystemRoot%\System32, %SystemRoot%\SysWOW64), имеют цифровую подпись Microsoft и соответствующие атрибуты (например, Protected Process Light для lsass.exe в современных версиях).

6. Скрытие файлов и обход стандартных средств просмотра

Вредоносные программы применяют разнообразные техники для сокрытия своего присутствия на диске:

6.1. Атрибуты файловой системы

Установка атрибутов Hidden и System — базовый метод, легко обнаруживается при настройке Проводника на показ скрытых файлов.
Использование альтернативных потоков данных (ADS — Alternate Data Streams) в NTFS. Файл может содержать скрытый поток (malware.exe:hidden.txt), недоступный через стандартные утилиты.

6.2. Длинные или некорректные имена

Использование имён длиннее 255 символов (ограничение Win32 API), что делает файл недоступным для большинства программ.
Включение недопустимых символов (например, C:\malware\<NUL>.exe) — ОС может не позволить создать такой файл напрямую, но при копировании из образа диска или через низкоуровневые вызовы он может существовать.

6.3. Ярлыки-обманки

Создание ярлыка с именем document.pdf.lnk, который визуально отображается как PDF-файл (если расширения скрыты). При запуске выполняется вредоносный скрипт.
Использование иконок, имитирующих стандартные типы файлов.

6.4. Вручную найти вредонос: практические советы

Использовать утилиты с поддержкой Win32 Long Path (robocopy, PowerShell с \\?\ префиксом).
Просмотр ADS через dir /R или Get-Item -Stream *.
Анализ с помощью Process Monitor (ProcMon) от Sysinternals: фильтрация по операциям CreateFile, RegOpenKey.
Проверка целостности системных файлов через sfc /scannow и DISM.
Сравнение контрольных сумм системных файлов с эталонными (например, из репозитория Microsoft).

7. ActiveX и другие устаревшие, но опасные технологии

ActiveX — технология компонентного программирования, разработанная Microsoft в середине 1990-х годов. Первоначально задумывалась как способ расширения функциональности веб-приложений за счёт выполнения нативного кода в контексте браузера Internet Explorer. ActiveX-элементы представляют собой COM-объекты, которые могут иметь полный доступ к системе при соответствующем уровне доверия.

Угрозы, связанные с ActiveX:

Выполнение произвольного кода: при загрузке веб-страницы может быть инициирована установка и запуск ActiveX-контрола без явного согласия пользователя (особенно в старых версиях IE).
Отсутствие песочницы: в отличие от современных веб-API, ActiveX не изолирован от ОС.
Повторное использование уязвимых контролов: многие легальные ActiveX-компоненты содержали критические уязвимости (например, переполнение буфера), которые эксплуатировались в атаках drive-by download.

Хотя Internet Explorer официально прекратил поддержку ActiveX (начиная с Microsoft Edge на базе Chromium), унаследованные системы по-прежнему используют IE в режиме совместимости, особенно в корпоративной среде. Кроме того, некоторые десктопные приложения (например, старые ERP- или BPM-системы) до сих пор полагаются на ActiveX для интеграции с оборудованием или локальными ресурсами.

Современные атаки редко используют ActiveX напрямую, но анализ исторических инцидентов показывает, что именно эта технология стала вектором для множества эпидемий (например, Conficker использовал уязвимость в ActiveX-компоненте Windows Shell).

Альтернативные устаревшие технологии с аналогичными рисками:

Java-апплеты — выполнялись в браузере до отключения в большинстве сред.
Microsoft Silverlight — имел ограниченную изоляцию и использовался для обхода CORS и других web-ограничений.
VBScript / JScript через WSH — до сих пор могут запускаться из проводника при открытии .vbs, .js файлов.

8. Удалённый захват компьютера и «призраки»

Термин «удалённый захват» обозначает несанкционированное получение полного контроля над устройством жертвы. Такие атаки реализуются с помощью Remote Access Trojan (RAT) — троянской программы с функциями удалённого администрирования.

Характеристики современных RAT:

Полный контроль над клавиатурой, мышью, экраном.
Возможность включения микрофона и веб-камеры.
Перехват буфера обмена, скриншоты, запись сессий.
Модульная архитектура: загрузка дополнительных плагинов по запросу.

Известные примеры: DarkComet, NjRAT, QuasarRAT, AsyncRAT. Многие из них имеют открытое исходное код и активно модифицируются злоумышленниками.

«Призраки»

Этот термин не имеет строгого технического определения, но в сообществе исследователей часто используется для обозначения вредоносных программ с крайне высоким уровнем скрытности, которые:

Не оставляют следов на диске (fileless malware).
Работают исключительно в оперативной памяти.
Используют легитимные системные утилиты (например, PowerShell, WMI, regsvr32.exe) для выполнения полезной нагрузки (living-off-the-land binaries — LOLBins).

Такие угрозы особенно опасны в корпоративной среде, где стандартные решения EDR (Endpoint Detection and Response) могут не фиксировать аномалии при использовании доверенных инструментов. Обнаружение требует анализа поведения: необычные цепочки вызовов, нестандартные параметры для wmic, неожиданные PowerShell-сценарии в памяти.

9. Майнеры: скрытая эксплуатация ресурсов

Криптомайнеры — класс вредоносного ПО, использующий вычислительные ресурсы устройства для добычи криптовалют (изначально Bitcoin, впоследствии — Monero, Ethereum и др.). После снижения прибыльности PoW-майнинга для централизованных пулов, злоумышленники перешли к массовой компрометации конечных устройств.

Типы майнеров:

Инсталлируемые: полноценные бинарники, устанавливающиеся как служба или процесс.
Браузерные: JavaScript-скрипты (например, на базе Coinhive), выполняющие майнинг в фоне вкладки.
Облачные: майнеры, размещённые на скомпрометированных серверах или виртуальных машинах (часто в облаках AWS, Azure).

Признаки заражения:

Стойкое повышение загрузки CPU/GPU.
Перегрев устройства, шум вентиляторов.
Снижение производительности ОС.
Неизвестные процессы в диспетчере задач с именами вроде xmrig, cpuminer.

Современные майнеры активно применяют антианализ: проверка на виртуальную машину, отключение при обнаружении отладчика, шифрование C2-каналов.

10. Рекламное и потенциально нежелательное ПО (Adware / PUP)

Adware (рекламное ПО) изначально не предназначено для кражи данных или разрушения системы. Его цель — монетизация через показ рекламы. Однако граница между adware и вредоносным ПО размыта:

Adware часто устанавливается без явного согласия (в комплекте с другими программами).
Нарушает приватность: отслеживает поведение пользователя, историю браузера.
Может понижать безопасность: отключает защиту браузера, добавляет ненадёжные сертификаты.
Некоторые образцы внедряют бэкдоры или загружают дополнительные угрозы.

PUP (Potentially Unwanted Program) — более широкая категория, включающая:

Панели инструментов браузера.
Сомнительные «оптимизаторы» системы.
Поддельные антивирусы (scareware).

Такое ПО часто распространяется через:

Фальшивые установщики (например, «видеокодеки», «проигрыватели»).
Рекламные сети с низкой репутацией.
Торрент-трекеры и файлообменники.

Хотя формально PUP может быть легальным (имеет EULA), его поведение навязчиво и дезинформирует пользователя, что ставит его в серую зону этики и безопасности.

Исторические кейсы вредоносного ПО

Изучение крупных инцидентов кибербезопасности позволяет выявить эволюцию методов, тактик и целей разработчиков вредоносного ПО. Ниже рассмотрены ключевые примеры, оказавшие влияние на развитие как атакующих, так и защитных технологий.

ILOVEYOU (2000)

Тип: Червь с элементами социальной инженерии
Платформа: Windows
Вектор распространения: Вложение электронной почты (LOVE-LETTER-FOR-YOU.TXT.vbs)

Несмотря на простоту, ILOVEYOU стал одним из самых разрушительных инцидентов своего времени. Вредонос представлял собой VBScript-файл, маскирующийся под текстовый документ. При запуске скрипт:

Перезаписывал файлы с расширениями .jpg, .mp3 и др.
Отправлял копию себя всем контактам из адресной книги Outlook.
Загружал дополнительный компонент для кражи паролей.

Особенности:

Использование доверия к формату «.txt» при скрытых расширениях в Windows.
Отсутствие цифровой подписи или обфускации — полагался исключительно на человеческий фактор.
Ущерб оценивался в миллиарды долларов; инцидент ускорил внедрение политик блокировки скриптов в корпоративных почтовых шлюзах.

Conficker (2008)

Тип: Червь с элементами ботнета и руткита
Платформа: Windows (XP–7)
Векторы: Уязвимость в RPC (MS08-067), автозапуск съёмных носителей, подбор паролей в домене

Conficker продемонстрировал высокий уровень инженерной сложности:

Использовал шифрование и домен-генерирующий алгоритм (DGA) для связи с C2-серверами.
Отключал службы обновления Windows и антивирусные продукты.
Применял мутацию кода (полиморфизм) и проверку среды выполнения.

Архитектурные инновации:

Поддержка peer-to-peer протокола для обмена командами между узлами ботнета.
Использование цифровой подписи (украденной у Realtek) для загрузки драйверов.
Разделение на несколько версий (A–E), каждая из которых вносила улучшения в устойчивость к анализу.

Conficker до сих пор считается образцом «профессионально разработанного» вредоносного ПО. Хотя его прямой вред был ограничен, он создал ботнет из десятков миллионов устройств.

Stuxnet (2010)

Тип: Целевая кибер-физическая атака (cyber-physical weapon)
Платформа: Windows + Siemens PLC (Programmable Logic Controller)
Векторы: Заражение через USB-носители, эксплуатация четырёх zero-day уязвимостей

Stuxnet был разработан, вероятно, государственными структурами (США и Израиль) для саботажа иранской ядерной программы. Его отличительная черта — воздействие на физическое оборудование.

Технические особенности:

Использовал уязвимости в lnk-файлах (CVE-2010-2568) для автозапуска с USB.
Перехватывал и модифицировал код, загружаемый в промышленные контроллеры Siemens S7.
Подделывал данные с датчиков, чтобы скрыть разрушение центрифуг.

Stuxnet стал первым доказанным случаем, когда вредоносное ПО напрямую повлияло на инфраструктуру критического назначения. Он лег в основу концепции APT (Advanced Persistent Threat) и изменил подход к защите OT/ICS-систем.

NotPetya (2017)

Тип: Вымогательское ПО с червеподобным распространением
Платформа: Windows
Векторы: Компрометация украинского ПО для бухгалтерии (M.E.Doc), эксплуатация EternalBlue (MS17-010)

Хотя NotPetya внешне напоминал ransomware (шифровал MBR и требовал выкуп в Bitcoin), его истинная цель — деструктивное воздействие. Шифрование было необратимым: ключи не сохранялись.

Методы распространения:

Использовал EternalBlue (утечка инструментов NSA) для горизонтального перемещения по сети.
Применял инструменты PsExec и WMIC для удалённого запуска.
Атаковал сервисы репликации домена через lsass.exe.

Ущерб превысил $10 млрд; пострадали FedEx, Maersk, Merck и другие транснациональные компании. NotPetya показал, как локальная атака может вызвать глобальные цепные реакции в цифровой экономике.

Emotet (2014–2021)

Тип: Модульный троян, loader, ботнет
Платформа: Windows
Векторы: Фишинговые вложения (макросы в Word), распространение через заражённые устройства в сети

Изначально созданный как банковский троян, Emotet эволюционировал в «вредонос-как-услуга» (Malware-as-a-Service). Он не наносил прямого вреда, но:

Собирал учётные данные и сессии.
Загружал вторичные угрозы: TrickBot, QakBot, Ryuk.

Технические достижения:

Использовал шифрование TLS с жёстко закодированными сертификатами.
Применял антиотладку и виртуализацию.
Динамически обновлял список C2-серверов через зашифрованные конфигурации.

Emotet был деактивирован в январе 2021 года в результате международной операции (Europol, ФБР, японская полиция). Его архитектура остаётся эталоном для современных модульных угроз.

Mirai (2016)

Тип: Ботнет для DDoS-атак
Платформа: Linux (встраиваемые устройства, IoT)
Векторы: Брутфорс по умолчанию заданным учётным данным (admin:admin, root:12345 и т.п.)

Mirai компрометировал миллионы маршрутизаторов, IP-камер и DVR-устройств, создав самый мощный на тот момент ботнет.

Особенности:

Исходный код опубликован в открытых источниках, что породило сотни клонов.
Использовал простейшие методы, но масштаб компенсировал низкую сложность.
Вызвал масштабные DDoS-атаки против DNS-провайдера Dyn, нарушив работу Twitter, Netflix, Reddit.

Mirai обнажил критическую уязвимость IoT-экосистемы: отсутствие базовой гигиены безопасности в устройствах массового потребления.

Антивирусы

Термин «антивирус» исторически возник из необходимости противодействовать программам, способным к саморазмножению и нанесению вреда цифровым системам. В узком смысле антивирус — это программное средство, предназначенное для обнаружения, блокировки, удаления или нейтрализации вредоносного программного обеспечения (malware). Однако в современном понимании антивирус — это не отдельная утилита, а компонент комплексной системы защиты, интегрированный в более широкую архитектуру информационной безопасности.

Современные антивирусные решения включают в себя механизмы статического и динамического анализа, поведенческий мониторинг, облачные сервисы, машинное обучение и интеграцию с операционной системой на уровне ядра. Они служат не только для борьбы с уже известными угрозами, но и для предсказания и предотвращения новых, ранее не встречавшихся атак.

Эта глава посвящена устройству, принципам работы и компонентам антивирусных систем, с акцентом на технический и архитектурный аспекты.

Базы антивирусов: структура, хранение и обновление

Что такое база антивируса

База антивируса — это набор данных, содержащий информацию о вредоносных программах и методах их идентификации. В её состав входят:

Сигнатуры — уникальные последовательности байтов или логические правила, однозначно идентифицирующие конкретный образец вредоносного ПО.
Эвристические правила — алгоритмы и шаблоны поведения, позволяющие обнаруживать неизвестные или модифицированные угрозы.
Метаданные угроз — информация о происхождении, семействе, методах распространения, уязвимостях, используемых угрозой.
Микропрограммы восстановления — инструкции по нейтрализации или лечению заражённых файлов.
Цифровые отпечатки — хэши известных чистых и вредоносных файлов (например, по SHA-256).

Эти данные организованы в структурированный формат, оптимизированный для быстрого поиска и применения в реальном времени.

Формат и организация баз

Базы антивирусов хранятся в проприетарных файлах, часто сжатых и зашифрованных. Используются как плоские структуры (например, хэш-таблицы), так и древовидные (например, префиксные деревья, B-деревья), позволяющие эффективно выполнять поиск по сигнатурам или фрагментам поведения. Некоторые антивирусы используют виртуальные машины для исполнения сигнатурных правил (например, ClamAV с его языком сигнатур).

Размер баз может достигать сотен мегабайт и даже гигабайтов. Например, база Kaspersky или Bitdefender содержит миллионы записей, включая данные не только о вирусах, но и о потенциально нежелательных программах (PUP), рекламном ПО (adware) и троянах.

Где и как хранятся базы

Базы обычно размещаются в защищённых каталогах операционной системы, доступ к которым ограничен правами администратора или специальных служб. Например:

Windows: %ProgramData%\KasperskyLab, %ProgramFiles%\DrWeb, %ProgramData%\Avast Software
Linux: /var/lib/clamav, /opt/kaspersky, /usr/share/avast

Современные антивирусы используют механизм sandbox-хранения — базы размещаются в изолированных контейнерах или защищённых разделах с контролем целостности (например, через технологию Microsoft WIM или аналогичные). Это предотвращает подмену или модификацию баз вредоносным ПО.

Защита баз от взлома и подмены

Для предотвращения компрометации антивирусные решения применяют несколько уровней защиты:

Цифровая подпись баз — каждое обновление баз подписывается закрытым ключом разработчика. При загрузке антивирус проверяет подпись с помощью доверенного открытого ключа.
Контроль целостности — хэширование файлов баз и регулярная проверка на соответствие эталонному значению.
Защита от записи — файлы баз монтируются в режиме «только для чтения» или защищаются через ACL (Access Control List) или AppArmor/SELinux на Linux.
Изоляция процесса обновления — механизм обновления запускается в отдельном процессе с минимальными привилегиями и под строгим контролем EDR-компонента.

Подмена баз — один из наиболее опасных векторов атаки (например, атака «антивирус как вектор»), поэтому ведущие вендоры используют защищённые каналы обновления (HTTPS с pinning сертификатов) и двухфакторную аутентификацию обновлений.

Обновление баз

Обновления баз происходят через регулярные запросы к облачным серверам вендора. Современные антивирусы применяют дельта-обновления — передаются только изменения, а не полная база. Это сокращает трафик и ускоряет применение новых сигнатур.

Механизм обновления включает:

Проверку версии локальной базы.
Запрос списка изменений с сервера.
Загрузку и проверку цифровой подписи обновления.
Применение обновления в фоновом режиме без перезапуска ядра защиты.

Некоторые системы используют превентивное обновление — серверы могут отправлять экстренные обновления при обнаружении активной кампании распространения нового вредоносного ПО (т.н. zero-hour response).

Сканирование и методы обнаружения угроз

Статический анализ

Статический анализ — проверка файла без его исполнения. Основные методы:

Сравнение с сигнатурами: файл читается побайтово, и его фрагменты сопоставляются с известными сигнатурами. Применяются алгоритмы, устойчивые к незначительным изменениям (например, поиск по «плавающим» сигнатурам — с допуском на полиморфизм).
Анализ структуры PE/ELF: проверка корректности заголовков исполняемых файлов, таблиц импорта/экспорта, секций кода/данных. Аномалии (например, секция .text с флагом записи) могут указывать на вредоносность.
Поиск подозрительных строк: наличие строк вроде cmd.exe /c, powershell -enc, CreateRemoteThread, RegSetValue может быть признаком трояна.

Динамический и поведенческий анализ

Динамический анализ подразумевает исполнение файла в контролируемой среде:

Песочница (sandbox): исполняемый файл запускается в изолированной виртуальной машине или контейнере. Всё поведение (создание процессов, сетевые запросы, изменения реестра) логируется и анализируется.
Эмуляция: вместо реального запуска файл проходит через эмулятор CPU или ОС. Это позволяет избежать рисков, связанных с запуском вредоносного кода.

Эвристические движки применяют правила поведения: если программа пытается записать себя в автозагрузку, скрыть своё окно и отправить данные на внешний IP — это поведение классифицируется как подозрительное.

Эвристика и ревизор

Эвристика — это метод обнаружения угроз на основе логических выводов и паттернов, а не точного совпадения с сигнатурой. Существуют два основных типа:

Файловая эвристика — анализ структуры, кода и метаданных файла.
Системная эвристика — мониторинг состояния системы в реальном времени (например, неожиданное появление большого числа скрытых процессов).

Ревизор — это компонент, периодически проверяющий целостность критических системных файлов и объектов ОС. Он сравнивает текущее состояние с эталонным (заранее сохранённым) и выявляет несанкционированные изменения. Например, если системный файл lsass.exe был заменён, ревизор зафиксирует расхождение хэшей и сгенерирует алерт.

Проверка запущенных процессов

Антивирусы сканируют не только файлы на диске, но и память запущенных процессов. Это необходимо для обнаружения:

Инжектов кода — когда в легитимный процесс (например, explorer.exe) внедряется вредоносный код.
Резидентных вирусов — программ, оставшихся в памяти после завершения основного процесса.
Rootkit’ов — скрытых компонентов, маскирующихся под системные функции.

Для этого применяются драйверы ядра (kernel-mode drivers), имеющие прямой доступ к памяти процессов и дескрипторам. На уровне ядра антивирус может читать таблицы виртуальной памяти, сравнивать образы в памяти с исходными файлами на диске и обнаруживать несоответствия.

Сигнатуры, нейропрофили и методы детектирования нового поколения

Сигнатуры: от байтовых последовательностей к логическим правилам

Традиционно сигнатура понималась как фиксированная последовательность байтов — так называемая статическая сигнатура. Однако подобный подход быстро стал неэффективным перед лицом полиморфных и метаморфных вирусов, способных изменять свой код при каждом заражении. Это привело к появлению гибких сигнатур:

YARA-правила — декларативный язык описания паттернов в файлах, сочетающий байтовые шаблоны, регулярные выражения и логические условия. Пример:
```
rule Suspicious_Powershell_Encoded
{
    strings:
        $cmd = /powershell.*-enc/
    condition:
        $cmd
}
```
Такие правила позволяют описывать не один файл, а целое семейство вредоносов.
Композитные сигнатуры — сочетают анализ структуры файла, его хэша и поведенческих черт. Например, сигнатура может срабатывать только если файл имеет определённый импорт API и пытается подключиться к известному C2-серверу.
Обфускационно-устойчивые сигнатуры — ориентированы на выявление логики, а не конкретного представления. Такие сигнатуры могут анализировать граф потока управления (control flow graph) или данные о вызовах функций, что делает их устойчивыми к простым методам обфускации.

Нейропрофили и машинное обучение

Современные антивирусные платформы всё чаще используют машинное обучение для выявления угроз. Вместо жёстко заданных правил система строит нейропрофиль — многомерное представление файла, основанное на сотнях признаков:

Энтропия секций (высокая энтропия может указывать на упаковку или шифрование).
Наличие редко используемых API-вызовов.
Статистика имён секций, размеров, флагов.
Поведенческие метрики (если файл ранее анализировался в песочнице).

Эти признаки подаются на вход нейросети или другому классификатору (например, градиентному бустингу), который выдаёт вероятность того, что файл вредоносен. Ключевое преимущество — способность обнаруживать ранее неизвестные угрозы (zero-day), не имеющие сигнатур.

Однако машинное обучение требует постоянного переобучения и тщательной калибровки порогов, чтобы избежать ложных срабатываний на легитимном ПО (например, пакетах обфусцированных коммерческих программ).

Микропрограммы лечения и Инструкции по нейтрализации угроз (ИПУ)

Когда антивирус обнаруживает заражённый файл, одной из задач становится его восстановление, а не просто удаление. Для этого используются так называемые микропрограммы лечения — специализированные скрипты или алгоритмы, предназначенные для конкретного типа вируса.

Например, если вирус добавил в конец исполняемого файла свой код и изменил точку входа (entry point), микропрограмма:

Определяет оригинальную точку входа (часто сохраняется вирусом в заголовке).
Удаляет внедрённый код (по известному смещению или сигнатуре).
Восстанавливает корректные флаги секций и контрольные суммы.
Обновляет хэш файла в системе целостности.

Такие микропрограммы хранятся в базе антивируса и ассоциированы с конкретными сигнатурами. Их создание — трудоёмкий процесс, требующий реверс-инжиниринга каждого нового вируса. В документации вендоров такие инструкции часто называют Инструкциями по нейтрализации угроз (ИПУ) — формализованными описаниями методов устранения последствий заражения.

Лечение и карантин: принципы нейтрализации угроз

Карантин как изоляционный механизм

Карантин — это защищённое хранилище, в которое перемещаются подозрительные файлы для предотвращения дальнейшего вреда. Это не просто папка, а изолированная среда со следующими свойствами:

Файлы в карантине переименовываются и зашифровываются, чтобы их невозможно было случайно или намеренно запустить.
Доступ к карантину ограничен привилегированным процессом антивируса.
Метаданные файла (путь, хэш, время обнаружения, тип угрозы) сохраняются отдельно.
Из карантина возможны только три действия: восстановить, удалить, отправить на анализ.

Карантин особенно важен при обнаружении файлов с недостоверной классификацией (например, эвристическое срабатывание на легитимный инструмент разработчика). Удаление в таких случаях может нарушить работоспособность системы, тогда как карантин даёт возможность ручной верификации.

Лечение заражённых файлов

Лечение возможно не для всех типов угроз. Оно применимо в основном к резидентным вирусам, файловым вирусам и макровирусам, которые внедряют свой код в существующие файлы, не заменяя их полностью.

Процесс лечения включает:

Идентификацию типа заражения — по сигнатуре определяется, какой именно вирус поразил файл.
Применение соответствующей микропрограммы — алгоритм извлекает или удаляет вредоносный код.
Восстановление структуры файла — исправление заголовков, таблиц импорта/экспорта, контрольных сумм.
Проверка целостности — сравнение с эталонным хэшем (если он известен) или проверка на соответствие формату.

В случае троянов, шпионских программ или рансомваров лечение, как правило, невозможно — такие файлы создаются как самостоятельные исполняемые модули, и их «лечение» сводится к полному удалению.

Лечение самой системы

Помимо файлов, антивирусы могут нейтрализовать угрозы на уровне системы:

Очистка реестра Windows: удаление автозагрузочных записей, вредоносных COM-объектов, перехватчиков DLL.
Восстановление хост-файла: если вирус модифицировал %SystemRoot%\System32\drivers\etc\hosts для перенаправления трафика.
Удаление планировщиков задач: отмена задач, созданных вредоносом.
Сброс параметров браузера: очистка перенаправлений, вредоносных расширений.

Некоторые решения включают системный ревизор, который после лечения сравнивает состояние системы с известным «чистым» снимком и предлагает дополнительные корректировки.

Цифровые подписи и доверенные файлы

Современные ОС (Windows, macOS, Linux с использованием IMA/EVM) активно применяют цифровые подписи для верификации подлинности системных компонентов.

Антивирусы интегрируются с этой инфраструктурой:

При сканировании файл проверяется на наличие валидной цифровой подписи от доверенного издателя (Microsoft, Apple, Mozilla и т.д.).
Отсутствие подписи или её недействительность (например, из-за модификации файла) является серьёзным индикатором компрометации.
Некоторые антивирусы поддерживают доверенные списки (whitelist): если файл подписан корпоративным сертификатом организации, он автоматически считается безопасным.

Однако злоумышленники всё чаще используют поддельные или украденные сертификаты, поэтому проверка подписи — лишь один из множества факторов в общей модели риска.

Восстановление системы

В случае масштабного заражения (например, активностью рансомвара или rootkit’а) антивирус может инициировать:

Откат системы — с использованием точек восстановления Windows (System Restore Points), если они не были уничтожены вредоносом.
Восстановление из резервной копии — через интеграцию с корпоративными системами резервного копирования.
Переустановку критических компонентов — например, перезапись системных файлов из кэша %WinDir%\System32\dllcache или через DISM (Deployment Image Servicing and Management).

В enterprise-средах антивирусы могут взаимодействовать с системами управления конфигурациями (например, SCCM, Ansible), чтобы автоматически переразворачивать заражённые хосты.

Сливы и утечки данных, инсайдерская деятельность

Что такое утечка данных? Это несанкционированное раскрытие конфиденциальной информации за пределы организации. Это может быть финансовая информация, внутренние переписки, исходный код, данные о клиентах, персональные данные пользователей, коммерческая тайна и любые другие данные, доступ к которым ограничен.

Она опасна потерей репутации, штрафами (юридическими последствиями), утечкой интеллектуальной собственности и конечно угрозой для бизнеса (взлом, вымогательство).

Какие бывают утечки данных?

Тип утечки	Описание
Внешняя утечка	Происходит в результате атаки извне, например, при взломе системы злоумышленником через уязвимости или подбор учетных данных
Инсайдерская утечка	Совершается сотрудником организации — намеренно (например, передача данных конкуренту) или по неосторожности (некорректное обращение с данными)
Случайная утечка	Происходит без злого умысла: отправка конфиденциального письма не тому получателю, потеря носителя информации (флешка, ноутбук)
Целенаправленная утечка	Злоумышленник систематически собирает данные, используя целевые атаки (например, APT-кампании)
Пассивная утечка	Сбор информации без активного доступа к системе: перехват трафика, сканирование открытых портов, анализ DNS-запросов
Активная утечка	Прямое копирование, скачивание или передача данных за пределы организации с использованием сети, USB, облачных хранилищ и т.д.

Инсайдер - человек, который имеет доступ к внутренним системам компании, например, работники, подрядчики, бывшие сотрудники, администраторы. Они имеют легальный доступ, могут обходить стандартные меры безопасности и не всегда действуют злонамеренно (часто - по ошибке).

Возможные действия, которые может предпринять инсайдер:

копирование данных на сторонние носители;
отправка данных (по E-mail);
удаление или повреждение информации;
злоупотребление полномочиями (просмотр личных данных клиентов и использование в своих целях);
сохранение прав доступа после увольнения.

Почему могут быть утечки?

Причина	Описание
Человеческий фактор	Ошибки персонала, игнорирование политик безопасности, попадание на фишинг, случайная отправка данных
Недостаточно развитые политики безопасности	Отсутствие чётких процедур управления доступом, аудита, резервного копирования и обучения сотрудников
Слабые пароли и отсутствие MFA	Использование простых или повторяющихся паролей, отсутствие многофакторной аутентификации повышает риск компрометации учетных записей
Уязвимости в ПО	Эксплуатация известных уязвимостей в приложениях и библиотеках, особенно при отсутствии своевременных обновлений
Неправильная настройка облачных сервисов	Открытые бакеты (например, S3), незащищённые API-эндпоинты, чрезмерные права доступа в облаке
Злоумышленники (внешние и внутренние)	Целенаправленные атаки со стороны внешних хакеров или действий недобросовестных сотрудников с целью хищения данных

Как защищаться от утечек?

Политика управления доступом:
- Принцип минимальных привилегий (Least Privilege);
- Разделение ролей (RBAC);
- Удаление доступа при увольнении.
Контроль активности:
- Аудит действий пользователей;
- Логирование и мониторинг (SIEM);
- Обнаружение аномалий (User and Entity Behavior Analytics — UEBA).
Обучение сотрудников:
- Регулярные тренинги по ИБ;
- Тестирование на фишинг;
- Повышение осведомлённости.
Защита данных:
- Шифрование (данных в покое и в движении);
- DLP-системы (Data Loss Prevention);
- Безопасное хранение и передача.
Аудит и тестирование:
- Регулярные пентесты;
- Сканирование уязвимостей;
- Анализ логов.
Реагирование на инциденты:
- План реагирования на утечки;
- Уведомление регуляторов (GDPR, CCPA и др.);
- Расследование и анализ причин.

Таким образом, чтобы не допустить утечек, определите, какие данные являются критически важными, назначьте уровень конфиденциоальности для таких данных, настройте контроль доступа, логирование, регулярно проверяйте уязвимости, проводите пентесты и обязательно проводите обучение сотрудников. Чтобы они не ошибались, лучше изначально грамотно организовать работу. Если есть риск утечки информации при использовании каких-то методов и инструментов в работе, лучше отказаться.

Научите также молодых специалистов грамотно «гуглить» и использовать нейросети - не нужно отправлять код целиком или искать по потенциально секретным вещам, лучше подменять названия таблиц, переменных, путей и всего, что может быть нежелательным к утечке, на какие-то другие, выдуманные названия. К примеру, заменить Users на Cats, или что-то вроде того.

Примеры известных утечек:

Утечка	Год	Последствия
Equifax	2017	Утечка персональных и финансовых данных 147 миллионов пользователей, включая номера социального страхования и паспортные данные
Yahoo	2013–2014	Компрометация около 3 миллиардов учётных записей, включая хеши паролей, секретные вопросы и контактную информацию
T-Mobile	2021	Утечка данных более чем 50 миллионов клиентов, включая ФИО, номера телефонов, адреса и паспортные данные
Colonial Pipeline	2021	Взлом системы по одному из учётных записей с простым паролем, что привело к остановке работы трубопровода и временному дефициту топлива на востоке США
Telegram	2023	Утечка порядка 80 миллионов записей пользователей, вызванная эксплуатацией уязвимостей в сторонних API-клиентах и открытом доступе к данным
Российские банки	2022–2023	Множественные инциденты с утечками персональных данных, кредитных историй и фрагментов переписок клиентов через сторонние сервисы и незащищённые интерфейсы

Легальный сбор информации

1. Два лица сбора данных

Сбор информации — фундаментальная активность любой информационной системы, будь то государственный регистр, корпоративная CRM-платформа или персональный дневник в облаке. В цифровой среде процесс трансформировался: объёмы выросли экспоненциально, методы — автоматизировались, а субъекты — множились. Вместе с этим возникла необходимость чётко разделять легальный и нелегальный сбор данных. В предыдущих разделах мы рассматривали преступные практики: взломы, фишинг, скрытую установку вредоносного ПО, промышленный шпионаж — всё то, что нарушает уголовное и административное законодательство.

Однако подавляющая часть собираемой в цифровом пространстве информации — результат легитимных, хотя и не всегда прозрачных, действий. Речь идёт о повседневной практике крупных корпораций, государственных органов, платформ и сервисов, которые собирают данные в рамках установленных правил, но часто — с минимальным осознанием со стороны пользователя.

Важно сразу уточнить: «легальный» не означает «этичный» или «безопасный». Легальность — юридическая категория, определяемая соответствием действий нормам закона. Этика — отдельный пласт, требующий анализа мотивов, последствий и степени информированности субъекта данных.

Эта глава посвящена именно легальному сбору информации: как он устроен, на каких основаниях осуществляется, какие данные собираются и зачем, а также какие механизмы регулируют этот процесс в разных юрисдикциях.

2. Что такое «легальный сбор информации»?

Под легальным сбором информации в контексте цифровых технологий понимается целенаправленное или автоматизированное получение данных о пользователях, устройствах, поведении или контексте с соблюдением действующего законодательства и установленных процедур согласия.

Ключевые элементы этого определения:

Целенаправленность или автоматизация: данные могут собираться как в рамках явного запроса (например, регистрация на сайте), так и пассивно — через логирование, куки, трекеры, метрики.
Субъект данных — физическое лицо, чьи персональные или поведенческие данные обрабатываются.
Согласие — правовой инструмент, с помощью которого субъект данных даёт разрешение на обработку своих данных. Однако согласие — не единственный правовой основание; о других — ниже.
Соответствие законодательству — основной критерий легитимности. В разных странах это могут быть GDPR (ЕС), CCPA/CPRA (Калифорния, США), ФЗ-152 (Россия), PIPL (Китай) и др.

Легальный сбор не предполагает «злоупотребления», но допускает максимально широкую интерпретацию интересов бизнеса, если она укладывается в правовое поле. Именно это создаёт ощущение двойственности: действия юридически безупречны, но вызывают дискомфорт у пользователей.

3. Почему компании собирают данные? Экономическая модель внимания

Главная причина легального сбора информации — монетизация поведенческих данных. Современная цифровая экономика построена на так называемой attention economy (экономике внимания): пользовательское внимание становится товаром, который продаётся рекламодателям.

Компании не заинтересованы в личной драме пользователя, его семейных конфликтах или внутренних переживаниях — им важны предсказуемые паттерны поведения, которые позволяют:

определить вероятность покупки товара;
оценить восприимчивость к рекламному сообщению;
классифицировать пользователя по сегментам (демография, интересы, уровень дохода);
оптимизировать интерфейсы и функциональность продукта;
прогнозировать отток или удержание.

Следовательно, собираемые данные — поведенческие сигналы, а не личные тайны. Это различие принципиально: корпорации не «подслушивают разговоры на кухне» в буквальном смысле (и, как правило, технически не заинтересованы в этом), но инферируют содержание этих разговоров по тому, какие запросы делаются в поисковике, какие страницы просматриваются, какие товары добавляются в корзину, но не покупаются.

Например, если пользователь в течение недели просматривает обзоры детских колясок, посещает форумы молодых родителей и ищет «лучшие роддома в Москве», алгоритмы могут с высокой вероятностью заключить, что он или его супруга находится в состоянии беременности — даже если об этом нигде прямо не сказано. Этот вывод будет использован для таргетирования рекламы подгузников, детского питания или страховых программ.

Таким образом, цель легального сбора — не наблюдение за личностью, а построение предсказательной модели поведения. Модель не требует знания «кто вы», но требует точного понимания «что вы, вероятно, сделаете».

4. Правовые основания для сбора данных

Согласно большинству современных регуляторных режимов (в первую очередь GDPR), обработка персональных данных возможна только при наличии одного из законных оснований:

Согласие субъекта данных — наиболее известное основание. Должно быть свободным, конкретным, информированным и недвусмысленным. Однако на практике «согласие» часто сводится к клику на баннер с куками или галочке «я прочитал пользовательское соглашение», что ставит под сомнение его добровольность.
Исполнение договора — если данные необходимы для предоставления услуги. Например, адрес доставки при заказе товара.
Соблюдение юридической обязанности — например, хранение логов по требованию регулятора.
Защита жизненно важных интересов — редкое основание, применимое в экстренных ситуациях.
Осуществление публичных полномочий — для государственных органов.
Преследование законных интересов контролёра данных — ключевое основание для бизнеса. Именно оно оправдывает сбор аналитических и маркетинговых данных без явного согласия, если интересы компании не превалируют над правами и свободами пользователя.

Последний пункт — наиболее спорный и широко используемый. Например, Google может утверждать, что имеет «законный интерес» в анализе поведения пользователя в Gmail для персонализации рекламы в YouTube, поскольку оба сервиса принадлежат одной экосистеме. Пользователь при этом не давал прямого согласия на такую кросс-сервисную обработку, но она признаётся легальной при соблюдении определённых условий.

5. Технические механизмы легального сбора данных

Легальный сбор информации опирается на целый арсенал технологий, многие из которых являются неотъемлемой частью современной цифровой инфраструктуры. Эти механизмы работают в фоновом режиме, часто без явного ведома пользователя, но их использование регулируется правовыми нормами и (в идеале) контролируется через механизмы согласия.

5.1. Куки (HTTP-куки)

Куки — один из самых старых и распространённых инструментов хранения данных на стороне клиента. Первоначально они были созданы для поддержания состояния сессии (например, авторизации), но быстро превратились в основной инструмент отслеживания поведения.

Существуют два основных типа:

Первые куки (first-party cookies) — устанавливаются доменом, который пользователь непосредственно посещает. Используются для функциональности: корзина в интернет-магазине, настройки языка, сохранение сессии.
Сторонние куки (third-party cookies) — устанавливаются доменами, отличными от посещаемого сайта. Обычно принадлежат рекламным сетям (Google Ads, Meta Pixel), аналитическим платформам (Google Analytics, Yandex.Metrica) или социальным виджетам.

Хотя сторонние куки всё чаще блокируются браузерами (Safari, Firefox, Chrome с 2024+), они долгое время были основой кросс-сайтового трекинга. При этом их использование признавалось легальным при условии информирования и получения согласия — отсюда повсеместные баннеры с уведомлениями о куки после вступления в силу GDPR.

5.2. Веб-маяки и пиксель-трекеры

Маяки (beacons) — это невидимые 1×1 пиксельные изображения, встроенные в веб-страницы, письма или приложения. При загрузке страницы браузер отправляет HTTP-запрос на сервер, где размещён этот пиксель, и в процессе передаёт метаданные: IP-адрес, User-Agent, время, реферер и идентификаторы сессии.

Пиксель-трекеры (например, Meta Pixel, TikTok Pixel) используются для:

подтверждения конверсий (покупка, регистрация);
построения ретаргетинговых аудиторий;
оценки эффективности рекламных кампаний.

Хотя сам по себе запрос выглядит безобидно, совокупность таких сигналов позволяет точно восстановить поведенческую карту пользователя. Использование таких трекеров считается легальным при условии раскрытия в политике конфиденциальности и получения согласия на маркетинговые цели.

5.3. Device Fingerprinting

Если куки можно удалить, а трекеры — заблокировать, то отпечаток устройства (device fingerprint) формируется на основе характеристик самого устройства и браузера: версия ОС, разрешение экрана, список установленных шрифтов, часовой пояс, поддерживаемые кодеки, WebGL-рендеринг и даже шум микрофона или акселерометра в мобильных устройствах.

Этот метод не требует хранения данных на устройстве — идентификация происходит в реальном времени на сервере. В ЕС и Калифорнии fingerprinting официально признан формой персональных данных, поскольку позволяет однозначно идентифицировать или профилировать пользователя. Следовательно, его использование требует согласия на обработку персональных данных, если применяется для профилирования или таргетинга.

5.4. SDK в мобильных приложениях

В мобильной экосистеме основным инструментом сбора становится Software Development Kit (SDK) — библиотека кода, встраиваемая разработчиком приложения от третьих лиц (Facebook, Adjust, AppsFlyer, Firebase). SDK может собирать:

уникальные идентификаторы устройства (IDFA в iOS, GAID в Android);
данные о геолокации;
информацию о покупках внутри приложения;
события взаимодействия (открытие экрана, клики, время сессии).

Apple и Google требуют от разработчиков раскрывать, какие SDK используются и с какой целью. В iOS с внедрением App Tracking Transparency (ATT) в 2021 году сбор IDFA стал возможен только после явного согласия пользователя. Это резко снизило эффективность таргетированной рекламы, но не отменило самого сбора — компании перешли к методам, не зависящим от идентификаторов (например, модели на основе агрегированных данных).

5.5. API-интеграции и обмен данными между сервисами

Крупные платформы (Google, Meta, Microsoft) позволяют сторонним сервисам интегрироваться через API. Например, вход через Google-аккаунт даёт приложению доступ к базовой информации: имени, электронной почте, аватару. Пользователь видит запрос на разрешение, но редко задумывается, что это разрешение — начало легального обмена данными между экосистемами.

Кроме того, сами платформы объединяют данные между своими сервисами. Покупки в Google Play, поиск в Chrome, просмотр видео на YouTube, местоположение в Maps — всё это может использоваться для единой модели пользователя. В рамках GDPR такая внутренняя передача данных оправдывается «законными интересами» и уведомляется в политике конфиденциальности.

6. Согласие как иллюзия контроля

Одна из центральных проблем легального сбора — разрыв между формальным соблюдением закона и реальной осведомлённостью пользователя. Согласие, требуемое регуляторами, на практике превращается в:

информационную перегрузку: политики конфиденциальности достигают десятков тысяч слов, написаны юридическим языком и редко читаются.
дизайн принуждения (dark patterns): кнопка «Принять всё» выделена ярко, а опции персонализации скрыты за несколькими кликами.
отсутствие реального выбора: отказ от согласия часто означает невозможность пользоваться сервисом («всё или ничего»).

В результате пользователь «соглашается», но не понимает, что именно он разрешает и какие последствия это повлечёт. С точки зрения права — это легально. С точки зрения этики и информационной автономии — это системный дефицит.

Тем не менее, именно эта модель — согласие плюс раскрытие — легитимизирует сбор данных в глазах регуляторов. Без неё даже самые безобидные аналитические инструменты становятся нарушением закона.

7. Регуляторные режимы: как законы определяют легальность

Легальность сбора информации напрямую зависит от юрисдикции. Разные правовые системы по-разному балансируют интересы бизнеса, государственного регулирования и прав субъектов данных. Ниже — ключевые модели регулирования.

GDPR (2016/679) — наиболее строгий и влиятельный регуляторный акт в области защиты персональных данных. Он применяется ко всем компаниям, обрабатывающим данные граждан ЕС, независимо от места регистрации.

Ключевые принципы:

Целевое ограничение: данные можно собирать только для конкретных, явных и законных целей.
Минимизация данных: собирается только то, что необходимо для заявленной цели.
Ограничение хранения: данные не могут храниться дольше, чем требуется.
Прозрачность: пользователь должен понимать, кто обрабатывает данные, зачем и на каком основании.
Право на возражение: пользователь может запретить обработку на основе законных интересов.

GDPR требует активного согласия для маркетинговой обработки и профилирования. Также он вводит обязанность по оценке воздействия на защиту данных (DPIA) при высоких рисках.

7.2. CCPA / CPRA (Калифорния, США)

California Consumer Privacy Act (CCPA), усиленный California Privacy Rights Act (CPRA) с 2023 года, устанавливает права для жителей Калифорнии:

Право знать, какие данные собираются и с кем делятся.
Право на удаление данных.
Право отказаться от «продажи» или «обмена» данных (под «продажей» понимается передача третьим лицам для рекламы).

Важное отличие от GDPR: CCPA не требует согласия на сбор, но даёт право отказаться от его коммерческого использования. Это отражает американский подход — не запрещать сбор, а обеспечивать контроль над его последствиями.

7.3. ФЗ-152 «О персональных данных» (Россия)

Федеральный закон №152-ФЗ регулирует обработку персональных данных на территории РФ. Основные особенности:

Обязательное уведомление Роскомнадзора о начале обработки (с 2023 года — только в отдельных случаях).
Хранение данных российских граждан на серверах в РФ.
Согласие является основным основанием, но допускает исключения (договор, закон).

На практике ФЗ-152 уступает GDPR по строгости: отсутствует прямое право на возражение против профилирования, слабо развита культура DPIA, а санкции применяются выборочно. Тем не менее, формально он создаёт рамки легальности.

7.4. PIPL (Китай), LGPD (Бразилия), PDPA (Сингапур)

Китайский Закон о защите персональной информации (PIPL, 2021) сочетает элементы GDPR и государственного контроля: строгие требования к согласию, обязательная локализация данных и усиленный надзор за кросс-граничной передачей.

Бразильский LGPD во многом вдохновлён GDPR, но с более мягкой системой штрафов.

Сингапурский PDPA делает ставку на саморегуляцию и гибкость, сохраняя баланс между инновациями и защитой.

8. Где заканчивается «законный интерес» и начинается злоупотребление?

Как уже отмечалось, «законный интерес» — наиболее уязвимое основание для легального сбора. Оно позволяет компаниям обрабатывать данные без согласия, если:

интерес является реальным и текущим (не гипотетическим);
обработка не нарушает основных прав и свобод субъекта данных;
достигается разумный баланс между интересами бизнеса и пользователя.

Однако на практике компании часто интерпретируют «законный интерес» чрезмерно широко. Например:

использование данных о геолокации для «улучшения сервиса», хотя реальная цель — таргетированная реклама;
объединение профилей из разных сервисов под предлогом «единого пользовательского опыта»;
сбор данных «на будущее», без чёткой цели.

Регуляторы ЕС уже вынесли ряд решений, ограничивающих такие практики. Например, в 2022 году европейские надзорные органы постановили, что реклама на основе поведенческого профилирования не может основываться на законном интересе — требуется согласие. Это решение существенно сузило пространство для «легального», но непрозрачного сбора.

Таким образом, легальность не статична: даже ранее разрешённые практики могут быть признаны незаконными по результатам разъяснений регуляторов или судебных решений.

9. Саморегуляция индустрии: попытка упорядочить хаос

Поскольку законодательство отстаёт от технологий, индустрия выработала механизмы саморегуляции.

Interactive Advertising Bureau (IAB) Europe разработал TCF — технический и правовой стандарт для управления согласием в цифровой рекламе. Он определяет:

как передавать информацию о целях обработки;
как фиксировать согласие пользователя;
как обмениваться данными между участниками цепочки (издатель → CMP → рекламная сеть).

Однако в 2022 году бельгийский регулятор признал TCF v2.0 нарушающим GDPR, поскольку он поощряет предварительно заполненные согласия и не обеспечивает реальный контроль. Это показывает, что даже отраслевые стандарты не гарантируют легальности.

9.2. Global Privacy Control (GPC)

GPC — технический сигнал (HTTP-заголовок), который пользователь может отправить через браузер или расширение, чтобы выразить желание не продавать или не делиться своими данными. Поддерживается в Калифорнии по закону: сайты обязаны уважать GPC-сигнал. Однако в ЕС его юридическая сила пока не признана.

10. Что может пользователь? Практические меры

Несмотря на системную асимметрию, пользователь не лишён инструментов:

Использование приватных браузеров (Brave, Firefox с усиленными настройками) и блокировщиков трекеров (uBlock Origin, Privacy Badger).
Отключение таргетированной рекламы через настройки Google, Apple, Meta.
Регулярное удаление куки и очистка истории.
Использование разных профилей браузера для разных целей (работа, шопинг, личное).
Внимательное чтение баннеров согласия и выбор детальных настроек (если доступны).
Подача запросов на доступ, исправление или удаление данных по GDPR или CCPA.

Эти меры не остановят сбор полностью, но позволяют снизить объём профилируемых данных и сохранить функциональность критически важных сервисов.

Инъекции

Инъекции — одна из наиболее фундаментальных и широко распространённых уязвимостей в сфере информационной безопасности. Под инъекцией понимается внедрение злоумышленником несанкционированного кода или данных в программную систему таким образом, что система интерпретирует или исполняет их как часть своей логики. Это приводит к нарушению целостности, конфиденциальности и доступности информации и ресурсов.

В основе инъекционных атак лежит недостаточная проверка, фильтрация или экранирование входных данных, предоставляемых пользователем. Злоумышленник, используя слабые места в архитектуре приложения, может манипулировать его поведением, получать доступ к конфиденциальным данным, выполнять произвольные команды на сервере, подменять контент или полностью компрометировать систему.

Инъекции не являются атакой конкретного типа — это общий паттерн уязвимости, проявляющийся в различных контекстах: базы данных, командные оболочки, языки разметки, динамические языки программирования и т.д. Ниже будут рассмотрены наиболее значимые виды инъекций, их механизмы, последствия и методы защиты.

Общая модель инъекции

Любая инъекция предполагает три основных компонента:

Контекст исполнения — среда, в которой интерпретируются или исполняются входные данные (например, SQL-интерпретатор, командная оболочка, JavaScript-движок браузера).
Данные, контролируемые атакующим — строка, отправляемая пользователем (через параметры URL, формы, заголовки HTTP и др.), которая затем встраивается в исполняемый код без надлежащей обработки.
Нарушение синтаксической или семантической границы — злоумышленник вводит специальные символы или конструкции, которые изменяют исходную логику построения запроса или команды.

Успешная инъекция происходит тогда, когда приложение не разделяет данные и код, позволяя атакующему «переписать» поведение системы с помощью внешнего ввода.

SQL-инъекции (SQL Injection, SQLi)

SQL-инъекция — наиболее известный и исторически значимый тип инъекции. Она возникает при некорректной передаче пользовательских данных в SQL-запросы, что позволяет атакующему изменить логику запроса к реляционной базе данных.

Механизм атаки

Рассмотрим простой пример на языке C# (аналогично проявляется в PHP, Java и других языках):

string query = "SELECT * FROM Users WHERE Login = '" + userInput + "'";

Если userInput содержит строку ' OR '1'='1, то результирующий запрос примет вид:

SELECT * FROM Users WHERE Login = '' OR '1'='1'

Это приведёт к выборке всех записей из таблицы Users, поскольку условие '1'='1' всегда истинно. Злоумышленник может не только обойти аутентификацию, но и модифицировать данные (INSERT, UPDATE, DELETE), извлекать данные из других таблиц (UNION SELECT), выполнять административные команды (в случае расширенных прав СУБД) или даже получить доступ к файловой системе.

Уровни угрозы

SQL-инъекции подразделяются на:

Классические (In-band): данные извлекаются через тот же канал, по которому отправляется инъекция (например, вывод ошибки или через UNION).
Слепые (Blind): приложение не возвращает прямых данных, но реакция на истинные/ложные условия позволяет по битам извлекать информацию.
Out-of-band: данные передаются через сторонние каналы (например, DNS- или HTTP-запросы), если есть сетевой доступ от СУБД.

Защита от SQLi

Эффективная защита строится на нескольких уровнях:

Параметризованные запросы (Prepared Statements): гарантируют строгое разделение между кодом и данными. Значения передаются отдельно от текста запроса и интерпретируются исключительно как данные.
Экранирование специальных символов: менее надёжный подход, подвержен ошибкам и зависит от контекста (СУБД, кодировки).
Принцип наименьших привилегий: учётная запись приложения в СУБД должна иметь минимально необходимые права (без DROP, FILE, xp_cmdshell и т.п.).
Статический и динамический анализ кода: обнаружение потенциально уязвимых паттернов на этапе разработки и тестирования.

Инъекции команд операционной системы (Command Injection, CMDi)

Command Injection возникает, когда веб-приложение или программное обеспечение передаёт непроверенные пользовательские данные в системные команды (например, через system(), exec(), Process.Start() и аналоги).

Пример уязвимости

import os
os.system("ping -c 1 " + user_input)

Если user_input содержит 8.8.8.8; cat /etc/passwd, то будет выполнен не только ping, но и команда чтения файла паролей. Символы ;, &&, |, \n позволяют атакующему конструировать произвольные последовательности команд.

Контекст уязвимости

Особенно опасны такие инъекции на серверах с высокими привилегиями, где приложение запущено от имени root или SYSTEM. Последствия — полный контроль над сервером, установка бэкдоров, эксплуатация внутренней сети.

Защита

Избегать вызова системных команд на основе пользовательского ввода.
Если вызов необходим — использовать белый список допустимых значений.
Применять строгую валидацию и экранирование (но надёжнее — отказаться от динамического построения команд).
Запускать приложения в изолированных средах (контейнеры, chroot, sandbox).

Межсайтовый скриптинг (Cross-Site Scripting, XSS)

XSS — это форма инъекции, при которой вредоносный JavaScript-код внедряется в веб-страницу, отображаемую в браузере жертвы. В отличие от SQLi и CMDi, XSS напрямую не атакует сервер, а эксплуатирует доверие пользователя к сайту.

Типы XSS

Отражённый (Reflected): вредоносный скрипт передаётся через URL (например, параметр поиска) и сразу возвращается в ответе сервера. Атака требует, чтобы жертва перешла по специально подготовленной ссылке.
Сохранённый (Stored): скрипт сохраняется на сервере (в комментариях, профилях, форумах) и отдаётся всем пользователям, просматривающим заражённый контент.
DOM-based: уязвимость возникает на стороне клиента — вредоносные данные модифицируют DOM-дерево без участия сервера (например, через location.hash, document.write).

Последствия

Кража куков сессии (включая HttpOnly в некоторых случаях).
Перенаправление на фишинговые страницы.
Логгирование нажатий клавиш (keylogging).
Выполнение действий от имени пользователя (например, перевод средств).

Защита

Экранирование контента: перед вставкой в HTML все специальные символы (<, >, ", ', &) должны быть заменены на HTML-сущности (<, > и т.д.).
Контекстно-зависимая обработка: правила экранирования различаются для HTML, атрибутов, JavaScript, CSS, URL.
Content Security Policy (CSP): механизм, ограничивающий источники загрузки скриптов, стилей и других ресурсов.
Фреймворковые средства: современные фреймворки (React, Angular, Vue) по умолчанию экранируют вывод, но ручные манипуляции (innerHTML, dangerouslySetInnerHTML) могут обойти защиту.

Обобщённые принципы защиты от инъекций

Несмотря на различия в контекстах, все инъекции подчиняются общим принципам предотвращения:

Разделение кода и данных: никогда не встраивайте пользовательские данные непосредственно в исполняемый код.
Белые списки: вместо попыток заблокировать «плохие» символы — разрешайте только известные безопасные значения.
Экранирование в соответствии с контекстом: если встраивание неизбежно, применяйте контекстно-зависимое экранирование, соответствующее целевой среде (SQL, OS, HTML и пр.).
Минимизация поверхности атаки: отключайте ненужные функции (например, xp_cmdshell в MS SQL, exec в PHP), ограничивайте права, используйте沙箱.
Тестирование и мониторинг: регулярное проведение тестов на проникновение, статический анализ кода, логирование подозрительных запросов.

Редкие, но критичные формы инъекций

Помимо широко известных SQL-, командных и XSS-инъекций, существует ряд специализированных форм внедрения вредоносного кода, возникающих в узкоспециализированных средах: XML-процессоры, LDAP-каталоги, XPath-выражения, NoSQL-базы данных и др. Эти уязвимости часто остаются вне поля зрения разработчиков, поскольку подсистемы, в которых они возникают, считаются «внутренними» или «некритичными». Однако в современных распределённых архитектурах такие компоненты нередко становятся точками входа для атак.

XPath-инъекции

XPath (XML Path Language) — язык запросов к XML-документам, аналогичный SQL для реляционных баз. Если веб-приложение строит XPath-выражения на основе непроверенного пользовательского ввода, возможно внедрение произвольной логики.

Пример

Предположим, приложение ищет пользователя в XML-файле:

<users>
  <user>
    <login>admin</login>
    <password>secret</password>
  </user>
</users>

XPath-запрос может выглядеть так:

string xpath = "/users/user[login='" + login + "' and password='" + password + "']";

Если злоумышленник введёт в поле логина ' or '1'='1, то запрос примет вид:

/users/user[login='' or '1'='1' and password='...']

Если система не проверяет количество возвращённых узлов, а считывает первый попавшийся — аутентификация будет обойдена. В отличие от SQL, XPath не имеет встроенных механизмов ограничения прав, поэтому уязвимость позволяет извлекать любые данные из всего XML-документа, включая поля, не предназначенные для отображения.

Защита

Использовать параметризованные XPath-выражения, если они поддерживаются (редко).
Применять строгую валидацию входных данных (белый список допустимых символов).
Избегать построения XPath-запросов на основе прямого пользовательского ввода.

LDAP-инъекции

LDAP (Lightweight Directory Access Protocol) — протокол для доступа к иерархическим каталогам (например, Active Directory). LDAP-инъекция возникает при некорректной обработке входных данных в поисковых фильтрах.

Пример

Фильтр может строиться так:

filter = "(uid=" + username + ")"

Если username содержит *)(uid=*))(|(uid=*, то фильтр превращается в:

(uid=*)(uid=*))(|(uid=*

Это может привести к обходу аутентификации или получению списка всех пользователей.

Особенности

LDAP использует собственный набор метасимволов: *, (, ), \, &, |, !. Их экранирование регламентировано в RFC 4515: каждый из этих символов должен быть заменён на \xx (шестнадцатеричное представление ASCII-кода).

Защита

Экранирование всех метасимволов в соответствии с RFC 4515.
Использование готовых библиотек для формирования фильтров (например, ldap.filter.escape в Python).
Применение строгой валидации (например, логин должен соответствовать регулярному выражению ^[a-zA-Z0-9_]+$).

NoSQL-инъекции

NoSQL-инъекции не являются прямым аналогом SQL-инъекций, поскольку большинство NoSQL-баз (MongoDB, CouchDB, Redis и др.) не используют строковые запросы в традиционном смысле. Вместо этого они принимают структурированные запросы — чаще всего в виде JSON-объектов или словарей. Уязвимость возникает при некорректной обработке пользовательских данных, которые интерпретируются как часть структуры запроса, а не как простые значения.

Пример (MongoDB)

Предположим, в приложении на Node.js происходит поиск по коллекции:

db.users.findOne({ username: req.body.username, password: req.body.password });

Если злоумышленник отправит JSON:

{
  "username": { "$ne": "" },
  "password": { "$ne": "" }
}

То MongoDB интерпретирует это как:

{ username: { $ne: "" }, password: { $ne: "" } }

Оператор $ne (not equal) означает «любое значение, кроме пустой строки». Таким образом, будет найден первый пользователь с непустыми логином и паролем — аутентификация обойдена.

В более сложных сценариях возможно использование операторов $where (выполнение JavaScript-кода на сервере MongoDB) или $regex для перебора данных побитно (аналог blind SQLi).

Защита

Строгая типизация входных данных: если ожидается строка — принимать только строки, отклоняя объекты.
Валидация структуры запроса: использование схем (например, Joi, Zod) для фильтрации и нормализации входных данных.
Отключение опасных операторов: в MongoDB можно запретить использование $where, $mapReduce и других функций на уровне базы.
Принцип наименьших привилегий: учётная запись приложения не должна иметь прав на выполнение административных команд.

Инъекции в динамические языки (eval-инъекции)

Многие скриптовые языки (JavaScript, Python, PHP, Ruby) поддерживают функции динамической интерпретации кода: eval(), exec(), Function(), import(), pickle.loads() и др. Использование таких функций с непроверенными данными представляет собой прямую инъекцию исполняемого кода.

Пример

user_input = request.GET['data']
result = eval(user_input)

Если user_input содержит __import__('os').system('rm -rf /'), последствия могут быть катастрофическими.

Особенности

Такие инъекции особенно опасны в средах с высокими привилегиями (например, административных панелях, внутренних инструментах). Часто разработчики считают, что «ввод контролируется», но забывают о возможностях сериализованных объектов (например, pickle в Python), которые при десериализации могут выполнять произвольный код.

Защита

Категорический отказ от eval() и аналогов в production-коде.
Использование безопасных альтернатив: JSON вместо eval для парсинга, шаблонизаторов вместо конкатенации кода.
При необходимости десериализации — использовать только доверенные форматы (JSON, XML с отключёнными DTD) и избегать собственных сериализованных объектов.
Изоляция среды выполнения (например, запуск в контейнере без доступа к файловой системе).

Объединяющий взгляд: модель «доверенной границы»

Все инъекции можно рассматривать через призму нарушения доверенной границы между данными и кодом. Приложение получает данные от внешнего агента (пользователя, API, файла) и передаёт их в интерпретатор (SQL, JS, OS shell и т.д.). Если граница между данными и кодом не защищена — интерпретатор не может отличить легитимные данные от вредоносных инструкций.

Фундаментальный принцип защиты — никогда не доверять внешним данным. Это означает, что:

Все входные данные должны считаться потенциально вредоносными до тех пор, пока не доказано обратное.
Построение исполняемой логики должно быть полностью отделено от передачи значений.
Контекст интерпретации должен быть максимально ограничен и изолирован.

Практические методы выявления и тестирования инъекций

Теоретическое понимание механизма инъекций необходимо, но недостаточно для обеспечения безопасности программных систем. Обнаружение уязвимостей требует системного подхода, сочетающего автоматизированные инструменты, ручной анализ и понимание контекста работы приложения.

1. Ручное тестирование (Manual Testing)

Ручное тестирование остаётся наиболее надёжным методом выявления сложных и контекстно-зависимых инъекций. Оно предполагает:

Анализ всех точек ввода: не только формы и URL-параметры, но и HTTP-заголовки (User-Agent, Referer), cookie, тела запросов (включая JSON, XML), файлы, веб-сокеты.
Фаззинг входных данных: подстановка специальных последовательностей, характерных для разных типов инъекций:
- Для SQLi: ', ", --, /*, UNION SELECT, SLEEP(), BENCHMARK().
- Для CMDi: ;, &, |, $(...), `...`, %0a, &&, ||.
- Для XSS: <script>, javascript:, onerror=, "><svg onload=...>.
- Для NoSQL: { "$ne": 1 }, { "$gt": "" }, { "$where": "..." }.
Наблюдение за поведением приложения: изменения в ответе, задержки (time-based blind), ошибки (error-based), перенаправления — всё это может быть индикатором уязвимости.
Использование прокси-инструментов: Burp Suite, OWASP ZAP позволяют перехватывать, модифицировать и повторно отправлять запросы, что критично для тестирования инъекций.

2. Автоматизированное сканирование

Автоматизированные сканеры уязвимостей (DAST — Dynamic Application Security Testing) могут быстро выявить классические инъекции, особенно отражённые формы XSS и SQLi. Однако они имеют ограничения:

Сложно обнаруживают слепые (blind) инъекции без чёткой сигнализации.
Часто дают ложные срабатывания (false positives) или пропускают уязвимости в нестандартных контекстах (например, GraphQL, WebSocket, SOAP).
Не понимают бизнес-логику приложения, что делает их беспомощными против логических уязвимостей.

Тем не менее, такие инструменты, как sqlmap (для SQLi), NoSQLMap (для NoSQL), dalfox (для XSS), являются мощными утилитами в руках специалиста и позволяют автоматизировать эксплуатацию подтверждённых уязвимостей.

3. Статический анализ кода (SAST)

SAST-инструменты анализируют исходный код или байт-код на наличие опасных паттернов:

Конкатенация строк с пользовательским вводом перед передачей в SqlCommand, os.system, eval, innerHTML.
Использование устаревших или небезопасных API.
Отсутствие вызовов функций экранирования.

Примеры инструментов: SonarQube, Checkmarx, Semgrep, Bandit (для Python), ESLint с плагинами безопасности (для JS/TS).

Важно: SAST не гарантирует отсутствие уязвимостей, но позволяет выявить рискованные участки кода на ранних этапах разработки.

4. Тестирование в CI/CD

Интеграция проверок на инъекции в процесс непрерывной интеграции позволяет выявлять регрессии и новые уязвимости до попадания кода в production. Это включает:

Запуск линтеров и SAST-сканеров при каждом коммите.
Автоматизированные unit- и интеграционные тесты с вредоносными входными данными.
Использование «загрязнённых» тестовых данных (taint analysis) для отслеживания путей передачи непроверенного ввода.

Стандарты и классификации

Инъекции официально признаны одной из самых критичных уязвимостей. В OWASP Top 10 инъекции (в широком смысле) неоднократно занимали первое место:

OWASP Top 10 2013, 2017: Injection (A1).
OWASP Top 10 2021: хотя формально вытеснены более широкими категориями (например, «Software and Data Integrity Failures»), инъекции по-прежнему входят в основные векторы атак.

В системе CWE (Common Weakness Enumeration) инъекции представлены множеством записей:

CWE-79 — XSS,
CWE-89 — SQL Injection,
CWE-78 — OS Command Injection,
CWE-90 — LDAP Injection,
CWE-611 — XML External Entity (XXE), близкая по сути,
CWE-94 — Code Injection.

Эти идентификаторы используются в отчётах, стандартах сертификации (PCI DSS, ISO/IEC 27001) и системах управления уязвимостями.

Архитектурные подходы к предотвращению инъекций

Помимо кодовых практик, важно внедрять архитектурные меры:

Zero Trust к входным данным: любые данные извне (включая внутренние микросервисы) рассматриваются как недоверенные.
Изоляция компонентов: базы данных, файловые системы, командные оболочки должны быть недоступны напрямую из публичных интерфейсов.
API-гейты и WAF: Web Application Firewall может блокировать известные сигнатуры инъекций, но не заменяет корректную реализацию. Лучше использовать его как дополнительный барьер.
Политики выполнения: например, в Node.js можно использовать vm2 вместо eval, в .NET — AppDomain с ограниченными разрешениями (хотя в .NET Core/AppDomain упразднён, требуется другой подход — например, изоляция в контейнерах).

Аудит

В контексте информационных технологий и цифровой трансформации организация любой сложности — от небольшого стартапа до крупного государственного учреждения — сталкивается с необходимостью систематической проверки корректности, безопасности и эффективности своих процессов, систем и данных. Такая проверка реализуется в форме аудита — структурированной, целенаправленной и документируемой деятельности, нацеленной на объективную оценку соответствия установленным критериям.

Термин «аудит» происходит от латинского audire — «слушать», что исторически отражало роль аудитора как внешнего наблюдателя, выслушивающего отчётность. В современной IT-практике аудит утратил сугубо пассивную роль и превратился в инструмент проактивного управления рисками, обеспечения соответствия и повышения зрелости процессов. Он охватывает как технические, так и организационные аспекты ИТ-инфраструктуры, включая программное обеспечение, данные, процессы разработки, эксплуатации и управления.

Аудит не следует путать с мониторингом, логированием или диагностикой. Хотя все эти функции могут использоваться в рамках аудита, сам он представляет собой методологически выстроенную деятельность с чётко определёнными целями, границами и критериями оценки. Ниже рассматриваются ключевые компоненты аудита в IT-контексте: его цели, подход к проведению и структура аудиторского журнала.

Цели аудита

Аудит в сфере информационных технологий выполняется не как формальность, а как стратегический инструмент управления. Его цели могут варьироваться в зависимости от контекста — регуляторного, внутреннего, проектного или операционного. Однако в обобщённом виде их можно сгруппировать в следующие категории:

1. Комплаенс (соответствие требованиям)

Одна из наиболее очевидных целей аудита — проверка соответствия нормативным, правовым и отраслевым стандартам. В IT-среде это включает соответствие таким регуляторным актам, как GDPR (в Европе), HIPAA (в здравоохранении США), ФЗ-152 (в России), а также стандартам информационной безопасности, например ISO/IEC 27001, PCI DSS, NIST SP 800-53 и другим.

Аудит комплаенса не ограничивается проверкой наличия документов. Он включает оценку фактической реализации требований: насколько политики безопасности соблюдаются на практике, как обеспечивается защита персональных данных, как организованы процессы управления доступом и т.д. Отсутствие соответствия может повлечь не только штрафы и санкции, но и репутационные потери, утрату доверия со стороны клиентов и партнёров.

2. Оценка рисков

Аудит служит мощным средством выявления уязвимостей, как технических (например, устаревшие версии ПО, незащищённые API), так и процессных (например, отсутствие двухфакторной аутентификации, слабые процедуры резервного копирования). В отличие от пентеста, который направлен преимущественно на эксплуатацию уязвимостей, аудит фокусируется на системной оценке рисков — выявлении зон повышенной уязвимости, анализе их потенциального влияния и вероятности реализации.

Оценка рисков в рамках аудита позволяет перейти от реактивной модели безопасности («действуем после инцидента») к проактивной («предотвращаем до инцидента»). Это особенно важно в условиях постоянно растущей сложности ИТ-ландшафтов, где облачные среды, микросервисы и интеграции третьих сторон создают новые векторы атак.

3. Оптимизация процессов

Аудит не ограничивается выявлением проблем. Он также ориентирован на повышение эффективности ИТ-операций. Анализ логов, метрик производительности, схем развертывания и архитектурных решений позволяет выявить избыточность, узкие места, дублирующие функции или неэффективное использование ресурсов.

Например, аудит системы CI/CD может показать, что 70 % времени сборки тратится на повторные, неоптимизированные задачи тестирования, или что тестовые среды развернуты с избыточной мощностью. Подобные выводы позволяют оптимизировать не только затраты, но и время вывода продукта на рынок.

4. Защита данных

В условиях цифровой экономики данные становятся самым ценным активом. Аудит обеспечивает проверку механизмов их защиты: шифрования (в покое и при передаче), управления правами доступа, анонимизации, мониторинга несанкционированных запросов и т.п. Особое внимание уделяется чувствительным данным — персональным, финансовым, медицинским и другим категориям, требующим особой защиты.

Аудит также помогает выявить так называемые «тёмные данные» — информацию, которая хранится, но не используется и при этом не защищена должным образом. Это создаёт избыточные риски без какой-либо бизнес-ценности.

Подход к аудиту

Проведение аудита требует чёткого методологического подхода. Он определяет, что проверять, насколько глубоко и в каком контексте. Эффективность аудита напрямую зависит от корректного определения его глубины и охвата.

Глубина аудита

Глубина аудита — это степень детализации, с которой анализируются объекты проверки. Она может варьироваться от поверхностного обзора до полного технического анализа на уровне исходного кода или сетевых пакетов.

Поверхностный аудит (high-level) фокусируется на наличии политик, процедур, отчётности и общей архитектуре. Он подходит для первичной оценки зрелости или для регулярных проверок в малоизменяющихся системах.
Средний уровень детализации включает анализ конфигураций, логов, метрик безопасности и производительности. Это типичный уровень для большинства внутренних аудитов.
Глубокий аудит предполагает проверку на уровне кода, сканирование уязвимостей, анализ поведения систем, ревью архитектурных решений и даже ручное тестирование. Такой подход необходим при работе с критически важными системами, при подготовке к сертификации или после серьёзного инцидента.

Выбор глубины зависит от целей аудита, критичности объекта, доступных ресурсов и уровня требуемой достоверности выводов. Важно понимать, что чрезмерная глубина без четкой цели может привести к избыточному объёму данных и затруднить интерпретацию результатов.

Набор событий и объектов для проверки

Аудит всегда имеет границы — он не может охватить всю ИТ-инфраструктуру целиком. Поэтому заранее определяется набор событий и объектов, подлежащих анализу. Это могут быть:

отдельные системы (например, CRM, ERP, базы данных),
процессы (например, управление инцидентами, разработка ПО, эксплуатация),
категории данных (например, персональные данные, логины, финансовые транзакции),
интерфейсы и интеграции (API, ETL-конвейеры, сторонние сервисы),
события безопасности (попытки входа, изменения привилегий, аномальные запросы).

Определение набора объектов требует предварительного анализа рисков и приоритетов. Например, если цель аудита — соответствие GDPR, то в фокус попадут все процессы и системы, обрабатывающие персональные данные. Если же аудит направлен на оптимизацию CI/CD, то объекты будут ограничены инструментами сборки, тестирования и деплоя.

Корректное определение границ предотвращает как недостаточность охвата (что делает аудит бесполезным), так и его размытость (что ведёт к неэффективному расходованию ресурсов).

Журнал аудита

Результаты аудита должны быть не только получены, но и зафиксированы таким образом, чтобы обеспечить воспроизводимость, прозрачность и возможность последующего контроля. Для этого используется журнал аудита — структурированный документ или набор записей, отражающих ход, содержание и выводы аудиторской деятельности.

Журнал аудита не следует путать с системными логами или журналами событий операционных систем, хотя последние могут служить источником данных для его формирования. Журнал аудита — это результат аналитической и экспертной работы, а не просто агрегация событий.

Структура журнала аудита, как правило, включает следующие обязательные компоненты:

1. Дата и время проведения проверки

Указание точного временного интервала, в рамках которого осуществлялся аудит, критически важно. Это позволяет соотнести результаты с состоянием системы на конкретный момент, особенно если инфраструктура динамична (например, облачные среды с автоматическим масштабированием или частыми релизами). В случае повторного аудита временные метки помогают отследить динамику изменений и выполнение ранее выданных рекомендаций.

2. Объект аудита

Здесь чётко формулируется, что именно подвергалось проверке: конкретная система (например, «микросервис AuthService в составе платформы ELMA365»), процесс (например, «процедура восстановления после сбоя в дата-центре»), категория данных (например, «журналы доступа к персональным данным пользователей») или их комбинация. Описание объекта должно быть достаточно точным, чтобы исключить неоднозначную интерпретацию.

3. Результаты

Это центральная часть журнала. Результаты включают:

Выявленные нарушения — конкретные отклонения от требований, стандартов или ожидаемого поведения. Каждое нарушение должно быть описано объективно, с указанием контекста, источника данных и степени критичности (например, по шкале CVSS для уязвимостей или по внутренней шкале рисков организации).
Рекомендации — предложения по устранению выявленных проблем. Рекомендации должны быть конкретными, выполнимыми и сопровождаться обоснованием. Например: «Заменить алгоритм хеширования паролей с MD5 на Argon2id в соответствии с рекомендациями OWASP Authentication Cheat Sheet».

Результаты не должны содержать оценочных суждений без доказательной базы. Аудиторская запись строится на фактах, а не на предположениях.

4. Ответственные лица

Журнал фиксирует как участников аудита, так и исполнителей, на которых возлагается реализация рекомендаций:

Аудиторы — лица или команда, проводившие проверку. В случае внешнего аудита указывается организация и её аккредитация.
Владельцы систем/процессов — ответственные за объекты аудита внутри организации.
Исполнители рекомендаций — сотрудники или подразделения, обязанные устранить выявленные недостатки.

Указание ответственных обеспечивает подотчётность и позволяет строить планы по устранению замечаний с чёткими сроками и контрольными точками.

В некоторых организациях журнал аудита интегрируется с системами управления инцидентами и задачами (например, Jira, ServiceNow), что позволяет автоматизировать отслеживание статуса рекомендаций.

Аудит как элемент непрерывного улучшения

Аудит не является разовым мероприятием. Его истинная ценность раскрывается в контексте цикла непрерывного улучшения (continuous improvement). После завершения аудита, реализации рекомендаций и верификации их эффективности следует новый цикл — уже с учётом изменений в системе, новых угроз или обновлённых регуляторных требований.

В зрелых организациях аудит интегрирован в процессы управления ИТ-услугами (ITIL), управления рисками (ISO 31000) и управления информационной безопасностью (ISO/IEC 27001). Он становится не инструментом наказания, а механизмом обратной связи, позволяющим поддерживать соответствие, устойчивость и эффективность цифровой инфраструктуры.

Кроме того, культура аудита формирует у сотрудников осознанное отношение к соблюдению стандартов и безопасности. Когда аудит воспринимается не как проверка «на вшивость», а как возможность объективной оценки и роста, он способствует повышению общей ИТ-зрелости.

Безопасность в Docker

Docker предоставляет несколько механизмов для повышения безопасности контейнеров.

Seccomp (Secure Computing Mode) ограничивает системные вызовы, доступные процессам внутри контейнера. Docker использует профиль seccomp по умолчанию, который блокирует опасные системные вызовы (например, chmod, chown). Можно создать собственный профиль seccomp и применить его:

docker run --security-opt seccomp=/path/to/seccomp-profile.json my-container

AppArmor контролирует права доступа к файлам и системным ресурсам. Включён по умолчанию в Ubuntu. Пример:

docker run --security-opt apparmor=unconfined my-container

SELinux предоставляет более строгий контроль доступа. Включён по умолчанию в RHEL/CentOS. Пример:

docker run --security-opt label=disable my-container

User Namespaces отображает UID и GID контейнера на другой UID/GID хоста. Даже если злоумышленник получит доступ к контейнеру с правами root, он не сможет получить такие же права на хосте. Пример - как включить:

dockerd --userns-remap=default

Capabilities позволяют ограничить привилегии контейнера. Docker предоставляет ограниченный набор capabilities (например, CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN). Можно удалить все дополнительные права и добавить только необходимые права.

Удаление всех дополнительных прав:

docker run --cap-drop ALL my-container

Добавление только необходимых прав:

docker run --cap-add NET_ADMIN my-container

Read-Only Filesystem делает файловую систему контейнера доступной только для чтения. Пример:

docker run --read-only my-container

Masking Sensitive Paths. По умолчанию контейнер имеет доступ к /proc, /sys и другим системным директориям. Как решение, можно использовать флаг --tmpfs или --mask:

docker run --tmpfs /run:rw,noexec,nosuid my-container

Когда Docker развёртывается в Production, рекомендуется удалять ненужные capabilities, включать seccomp и AppArmor/SELinux, использовать user namespaces, защищать файловую систему от изменений, использовать минимальные базовые образы (тот же alpine), создавать отдельные сети для контейнеров, и использовать инструменты мониторинга. Всё это можно совместить. Пример безопасного запуска контейнера:

docker run \
  --name secure-container \
  --read-only \
  --cap-drop ALL \
  --cap-add CHOWN \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --security-opt apparmor=custom-profile \
  --user 1000:1000 \
  --network isolated-network \
  my-container

Docker Secrets - встроенная функция Docker, предназначенная для безопасного хранения и передачи конфиденциальных данных (например, паролей, API-ключей, сертификатов) между контейнерами. Она доступна только в режиме Docker Swarm, но может быть адаптирована и для других сценариев.

Docker Secrets позволяет хранить конфиденциальные данные в зашифрованном виде, передавать секреты только в те контейнеры, которые их запрашивают, и обеспечивать изоляцию данных, чтобы они не попадали в образы или логи. Секреты шифруются как на диске, так и при передаче, доступны только тем сервисам, которым они предназначены, и такая технология упрощает управление конфиденциальными данными.

Как работает Docker Secrets?

Создаётся секрет с помощью команды docker secret create:

echo "my-secret-password" | docker secret create db_password -

При создании сервиса нужно указать секрет (привязав его к сервису):

docker service create \
  --name my-app \
  --secret db_password \
  my-app-image

Секрет монитруется в файловую систему контейнера по пути /run/secrets/<имя_секрета>. Например:

cat /run/secrets/db_password

Для обеспечения безопасности контейнеров важно использовать комплексный подход. Вот основные аспекты:

Шифрование томов производится, к примеру, через LUKS (Linux Unified Key Setup) или другие инструменты для шифрования данных на уровне хоста;
Шифрование сетевого трафика - используется TLS для защищённой передачи данных между контейнерами, настроить сертификаты для HTTPS.
Тома используются для хранения данных вне контейнера - доступ ограничен и предоставляется только нужным контейнерам;
Конфиденциальные данные хранятся в секретах, а не в переменных окружения и файлах.

Альтернативами Docker Secrets являются HashiCorp Vault и Kubernetes Secrets.

HashiCorp Vault — это инструмент для безопасного управления секретами (пароли, ключи, токены) и защищенного доступа к ним. External Secrets Operator — это оператор Kubernetes, который позволяет синхронизировать секреты из внешних систем (например, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) с секретами Kubernetes.

Kyverno — это политика безопасности для Kubernetes, которая позволяет автоматически применять правила и ограничения к ресурсам кластера - проверка корректности манифестов, автоматическое изменение манифестов (мутация), генерация новых ресурсов на основе политик и логирование нарушений политик (аудит).

Информационная безопасность
Методы защиты информации
Сертификаты, MITM
Безопасность приложений
Шифрование
Авторизация и аутентификация
Устаревшие подходы
Уровни доверия и SSL/TLS
Методы проверки подлинности
Вирусы и вредоносные программы
Антивирусы
Сливы и утечки данных, инсайдерская деятельность
Легальный сбор информации
Инъекции
Аудит
Безопасность в Docker

Информационная безопасность​

Конфиденциальность​

Целостность​

Доступность​

Опасности и безопасность​

Методы защиты информации​

Системный подход к защите информации​

Классификация методов защиты информации​

По уровню реализации​

По функциональному назначению​

Криптографические методы​

Защита на уровне систем и сетей​

Безопасность операционных систем и хостов​

Облачная безопасность​

Защита приложений и данных​

Защита данных​

Управление доступом и идентификацией​

Резервное копирование и восстановление​

Мониторинг, логирование и реагирование​

Стандарты и соответствие требованиям (Compliance)​

Сертификаты, MITM​

Безопасность приложений​

Безопасность фронтенда​

Безопасность бэкенда​

Что важно добавить в проект для безопасности​

Безопасность в разных языках​

Защита API​

Контроль и отслеживание​

Отслеживание действий​

Шифрование​

Авторизация и аутентификация​

1. Аутентификация: «Кто ты?»​

Виды аутентификации​

Готовые решения​

2. Авторизация: «Что тебе разрешено?»​

Модели управления доступом​

Механизмы авторизации​

3. JSON Web Tokens (JWT): архитектура и применение​

Структура JWT​

Применение JWT​

Ограничения и риски​

4. Валидация входных данных и управление доверием​

Белый и чёрный списки​

Библиотеки валидации​

5. Управление сессиями и stateful-подход​

Как работает сессия​

Преимущества сессий​

Недостатки​

6. Готовые фреймворки: Identity, Keycloak, Auth0​

ASP.NET Core Identity​

Keycloak​

Auth0 и Okta​

7. Единый вход (Single Sign-On, SSO)​

Принцип работы​

Стандарты SSO​

Преимущества SSO​

Риски​

8. Интеграция аутентификации и авторизации в разные типы приложений​

8.1. Веб-приложения​

8.2. Десктопные приложения​

8.3. Мобильные приложения​

9. Практические рекомендации по проектированию системы доступа​

Устаревшие подходы​

1. Устаревшие криптографические хэш-функции​

MD5​

SHA-1​

2. Небезопасные алгоритмы симметричного шифрования​

DES (Data Encryption Standard)​

3DES (Triple DES)​

ECB (Electronic Codebook) — режим шифрования​

3. Хранение паролей без соли (salt)​

4. Хранение секретов в открытом виде​

Plain text (открытый текст)​

5. Самопальные криптографические схемы​

6. Использование устаревших протоколов и механизмов​

Уровни доверия и SSL/TLS​

Методы проверки подлинности​

1. Sender Policy Framework (SPF)​

Назначение​

Принцип работы​

Информационная безопасность

Конфиденциальность

Целостность

Доступность

Опасности и безопасность

Методы защиты информации

Системный подход к защите информации

Классификация методов защиты информации

По уровню реализации

По функциональному назначению

Криптографические методы

Защита на уровне систем и сетей

Безопасность операционных систем и хостов

Облачная безопасность

Защита приложений и данных

Защита данных

Управление доступом и идентификацией

Резервное копирование и восстановление

Мониторинг, логирование и реагирование

Стандарты и соответствие требованиям (Compliance)

Сертификаты, MITM

Безопасность приложений

Безопасность фронтенда

Безопасность бэкенда

Что важно добавить в проект для безопасности

Безопасность в разных языках

Защита API

Контроль и отслеживание

Отслеживание действий

Шифрование

Авторизация и аутентификация

1. Аутентификация: «Кто ты?»

Виды аутентификации

Готовые решения

2. Авторизация: «Что тебе разрешено?»

Модели управления доступом

Механизмы авторизации

3. JSON Web Tokens (JWT): архитектура и применение

Структура JWT

Применение JWT

Ограничения и риски

4. Валидация входных данных и управление доверием

Белый и чёрный списки

Библиотеки валидации

5. Управление сессиями и stateful-подход

Как работает сессия

Преимущества сессий

Недостатки

6. Готовые фреймворки: Identity, Keycloak, Auth0

ASP.NET Core Identity

Keycloak

Auth0 и Okta

7. Единый вход (Single Sign-On, SSO)

Принцип работы

Стандарты SSO

Преимущества SSO

Риски

8. Интеграция аутентификации и авторизации в разные типы приложений

8.1. Веб-приложения

8.2. Десктопные приложения

8.3. Мобильные приложения

9. Практические рекомендации по проектированию системы доступа

Устаревшие подходы

1. Устаревшие криптографические хэш-функции

MD5

SHA-1

2. Небезопасные алгоритмы симметричного шифрования

DES (Data Encryption Standard)

3DES (Triple DES)

ECB (Electronic Codebook) — режим шифрования

3. Хранение паролей без соли (salt)

4. Хранение секретов в открытом виде

Plain text (открытый текст)

5. Самопальные криптографические схемы

6. Использование устаревших протоколов и механизмов

Уровни доверия и SSL/TLS

Методы проверки подлинности

1. Sender Policy Framework (SPF)

Назначение

Принцип работы